Support tool groups defined by interfaces or classes for *ToolProviders

[scottslewis]

Add sync and async tool group providers.

In org.springaicommunity.mcp.provider are classes for creating 'tool providers' from Object's/beans...e.g.

AsyncMcpToolProvider and SyncMcpToolProvider

I propose that sync and async 'tool group' providers be created that restrict the tool specification creation/processing to a 'tool group' class specified upon construction.

This would allow easy and dynamic creation of 'tool groups' defined by a java interface or class. One way to use this would be to have service interfaces, annotated with sync and/or async tool methods that are exposed as osgi services, with a clear separation between the service interfaces contract (including the MCP description metadata) and the service implementation.

[scottslewis]

@tzolov

When I originally posted this request for (tool group provider) I was thinking of 4 new classes....i.e. SyncMcpToolGroupProvider, etc. That's what's in the pr. It's also what I've implemented elsewhere MCPToolGroups with an example usage that looks like this:

		toolspecs = new SyncMcpToolGroupProvider(this, ExampleToolGroup.class).getToolSpecifications();

I realized that a much more elegant approach would be to simply change the current provider constructors from (e.g.):

	public SyncMcpToolProvider(List<Object> toolObjects) {
...impl
	}

to

	public SyncMcpToolProvider(List<Object> toolObjects, Class<?>... groups) {
....appropriate impl here
	}

The users of the tool providers could decide to use either

toolspecs = new SyncMcpToolProvider(toolObjects);   

OR

toolspecs = new SyncMcpToolProvider(toolObjects, MyInterface.class, MyClass.class)

A more general constructor seems like a nice solution to me, because it doesn't change the original/bean usage at all...i.e. 0 groups specified means all of them, but also supports a more general usage with the developer specifying the groupings/annotated classes that they want to limit the specification creation to.

I'm willing to do the impl of this if you want...the MCPToolGroups already has an impl that works fine/passes tests in pr. I'll add the appropriate group test cases also.

[scottslewis]

@tzolov @markpollack @TheEterna

I've decided to make available in a new repo the support for dynamic tool groups, based upon the mcp-annotation *ToolProviders classes

https://github.com/ECF/MCPToolGroups

I'm willing to contribute any/all of this work (i.e. the *ToolProviders, test code, example code in appropriate runtime environment) to the mcp-annotations project, as long as it remains an open source project. Just wanted to clarify that.

[TheEterna]

@tzolov @markpollack @TheEterna

I've decided to make available in a new repo the support for dynamic tool groups, based upon the mcp-annotation *ToolProviders classes

https://github.com/ECF/MCPToolGroups

I'm willing to contribute any/all of this work (i.e. the *ToolProviders, test code, example code in appropriate runtime environment) to the mcp-annotations project, as long as it remains an open source project. Just wanted to clarify that.

I’m somewhat curious about your project. While I don’t work on OSGi development myself, I believe the core logic of this project lies within McpToolGroupProvider. The intended functionality is to group components, allowing for flexible selection of the actual ToolProviders to be scanned—and this is indeed quite useful.

That said, I’ve been thinking: given that the project is positioned more as a base project, primarily meant to be invoked by other projects, code that is lightweight, concise, and atomic might be better suited for it. I think more complex functionalities should be left for developers to implement on their own.

Therefore, I consider your decision to split the project a great one. Thank you for your contributions to the open-source community!

[scottslewis]

Although I appreciate the compliments below, I still believe that the users of tool providers in the mcp-annotations project would benefit greatly from the simple addition of Class... toolGroups to their constructor as in the attached pr...and not have to deal with a separate jar or bundle to download, import, deploy etc.

On Mon, Sep 8, 2025, 8:18 PM han ***@***.***> wrote: *TheEterna* left a comment (spring-ai-community/mcp-annotations#13) <#13 (comment)> @tzolov <https://github.com/tzolov> @markpollack <https://github.com/markpollack> @TheEterna <https://github.com/TheEterna> I've decided to make available in a new repo the support for dynamic tool groups, based upon the mcp-annotation *ToolProviders classes https://github.com/ECF/MCPToolGroups I'm willing to contribute any/all of this work (i.e. the *ToolProviders, test code, example code in appropriate runtime environment) to the mcp-annotations project, as long as it remains an open source project. Just wanted to clarify that. I’m somewhat curious about your project. While I don’t work on OSGi development myself, I believe the core logic of this project lies within McpToolGroupProvider. The intended functionality is to group components, allowing for flexible selection of the actual ToolProviders to be scanned—and this is indeed quite useful.

Yes. That said, I’ve been thinking: given that the project is positioned more as

a base project, primarily meant to be invoked by other projects, code that is lightweight, concise, and atomic might be better suited for it. I think more complex functionalities should be left for developers to implement on their own.

Although imho Osgi services are an excellent fit for this...because of dynamics support and other things, I think dev consumers of the ToolProviders in this project could also use it to good effect without osgi...eg spring beans. Therefore, I consider your decision to split the project a great one. Thank

you for your contributions to the open-source community!

Fwiw, I would prefer it to be contributed here for ease of access...and remain willing to do so. Just for the record, there are no osgi dependencies in the actual provider code...just in the examples. —

…

Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABHB5EWQIDCIB7XU7XBAYD3RZBHVAVCNFSM6AAAAACEGTLON6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENRYG4YTANRXGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[scottslewis]

Therefore, I consider your decision to split the project a great one. Thank
you for your contributions to the open-source community!
Fwiw, I would prefer it to be contributed here for ease of access...and
remain willing to do so. Just for the record, there are no osgi
dependencies in the actual provider code...just in the examples.

FWIW, the only dependencies in the ToolProvider classes are precisely the same as what mcp-annotations is using currently. So these classes would be a drop-in generalization of the existing providers. That's what the pr #40 is about (not anything to do with OSGi at all).

I do also think that it would allow more consumers of mcp-annotations to deploy mcp-annotations as an osgi bundle (as mcp-java-sdk already does), thus issue #11, but as I said there are no OSGi or other new dependencies in the ToolProvider code at all.