Use Cases for Grouping of Tools, Prompts, Resources #1772
Replies: 6 comments 3 replies
-
|
A new-to-me use case having to do with server-side governance (of tools and resources) is described in this link |
Beta Was this translation helpful? Give feedback.
-
|
MCP 'Gateway' Server Use Cases for Grouping There are a number of use cases for grouping having to do with providing an MCP Gateway Server that exposes sets/groups of Tools, Resources, and Prompts (as well as other services) that are actually implemented by a service provider via an architecture like this: graph TD
MCP_Client[MCP Client]<--> MCP_Gateway_Server[MCP Gateway Server: Tools, Resources, Prompts]
subgraph Existing Services as Tools
subgraph ToolGroup
Other_MCP_Servers[Other MCP Servers]
REST_API[Rest API]
DB[Database]
end
Other_Models[Other Models or Agents]
Legacy[Legacy Services]
Proxy[Proxied Services]
Other[Other Services]
end
MCP_Gateway_Server<---> Other_MCP_Servers
MCP_Gateway_Server<---> REST_API
MCP_Gateway_Server<--->DB
MCP_Gateway_Server<--->Other_Models
MCP_Gateway_Server<--->Legacy
MCP_Gateway_Server<--->Proxy
MCP_Gateway_Server<--->Other
Considering Tools only, there are many scenarios where it would be valuable for the MCP Server Gateway to 'wrap' one or more services (or combinations of services) and expose the services on the right as a group of MCP Tools to MCP Clients. This is a kind of facade pattern as the MCP Server Gateway exposes a facade to MCP clients, and that facade/api is actually a number of services...some examples of which are given on the right. With the availability of grouping of tools (for example), defined on the mcp server gateway, new facades, consisting of sets of tools (for example) can be exposed to MCP Clients, taking advantage of existing/available services and/or subsystems. A working example of the use of groups for presenting a facade of tools is given here. As described in the repo readme, an arithmetic 'tool group', with 'add' and 'multiply' Tool implementations is created dynamically on the MCP Server. In the 'remote' examples the ExampleToolGroup instance is a dynamically discovered and created proxy for a remote service implementation. MCP tools are are then created from the proxy at runtime, as is the Arithmetic tool group by the addToolGroups call here One of the assumed requirements for the MCP Gateway Server is the ability to add/remove Groups, Tools, Resources, and Prompts dynamically...i.e. without MCP Gateway Server restart. |
Beta Was this translation helpful? Give feedback.
-
|
A number of use cases presented here having to do with
|
Beta Was this translation helpful? Give feedback.
-
|
We now have tasks. Any use cases we should also consider for the new primitive? It's an async version of tool essentially so i don't know if there would be anything use case wise that is independent of tools for groups, but something to ponder on. |
Beta Was this translation helpful? Give feedback.
-
|
Is there an SEP or draft schema for tasks? And any sdk implementations somewhere? If an async (invoke) of tool then it would make sense (to me) that Groups could be used to group tasks, along with Tools, Prompts, and Resources. Maybe Grouping could structure multiple related (long-running) tasks as s use case...as many workflows would likely require long-running tasks...e.g. for sequencing/managing concurrency. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it seems like it's going to be the top line feature advertised of the 11/25 spec release looking at the drafted blog. Should probably make sure the SEP for groups has note on tasks. Obviously the point of the groups sep is that it's generic, but good to call out this new primitive being added post-design does not affect at all the design of groups as evidence that it truly is generic / future proof |
Beta Was this translation helpful? Give feedback.
-
Very good point. I'll update the Group Primitive proposal. I haven't yet had a chance to stare at the tasks schema additions. Please don't let me forget this. |
Beta Was this translation helpful? Give feedback.
-
|
A very interesting examination of (mostly server-side use cases) Some of the use cases presented could be well-supported through a grouping primitive (dev workflows, debugging, testing, documentation, non-dev mcp server creation, discovery). |
Beta Was this translation helpful? Give feedback.
-
|
A Group primitive could help with the problems of Tool-Space Interference as described by this MS Research work: How could grouping help?
|
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.
-
Pre-submission Checklist
Discussion Topic
SEP #1300 was a proposal for adding Groups and Tags support to the MCP protocol specification, specifically for Tools.
One part of the feedback about this proposal from the core maintainers, as summarized here was that a Groups proposal should probably include the ability to Group Prompts, and Resources (i.e. the other existing primitives) as well as Tools.
This discussion is intended so that community input can be provided and recorded (to be used for driving specification and implementation choices) about use cases for a Group primitive (i.e. a notion of a Group in the MCP protocol that can be used with Tools, Resources, and Prompts and possibly others).
For Tool groups specifically, #1300 and #993 have descriptions of relevant use cases...e.g. client organization/presentation/lookup/search tools. Before proposing a new use case in comments for this discussion, please review the discussions on #1300 and #993 to avoid duplication.
As a result of the #1300 review, a new working group has been created: primitive-grouping-wg, Please consider joining this working group and/or engaging people in this working group via the discord channel.
This working group currently meets at 11:30am ET every Monday. See here for meeting information, notes from previous meetings, and upcoming meetings. The working group meetings (and discord channel) are open to all.
The working group meeting on Nov, 3 was focused on discussing grouping use cases. Please see this discussion and attached documents.
This discussion is to solicit and record community input about use cases for grouping of Tools, Prompts, and Resources...and explicitly not to propose or defend specific design or implementations of grouping.
If you have a use case that has not been articulated elsewhere, please consider describing it publicly as a comment in this discussion. Or if you have a use case that has been articulated else where, please express your support for addressing that use case. Clarifying questions about use cases are of course welcome. Please do not denigrate or diminish other commenter's use cases.
As MCP is a protocol specification, it may be useful to categorize your use case as 'client-based' (e.g. organization for human dev clients and/or model clients), or 'server-based' ...e.g. Tool organization, gateway support, orchestration, abstraction, scaling through grouping, etc). Clarity in your use case about 'who/what is/are the users' of the grouping capability will be appreciated.
Presenting a short 'user story' to illustrate your use case is welcome.
The working group will monitor and occasionally summarize this discussion, so that designs/approaches/proposals can be evaluated relative to their ability to address the grouping use cases recorded here and provide input to the specification process.
Thank you for your contribution and participation.
Beta Was this translation helpful? Give feedback.
All reactions