Building MCP Servers: Dynamic Tool Groups

Currently, adding tools to MCP servers is a static process.  i.e. a new tool is designed and implemented, MCP meta-data (descriptions) added via annotations, decorators, or code, the new code is added to the MCP server,  things are compiled and started, tested, debugged, etc.

As well, there is currently no mcp concept of tool 'groups'...i.e. multiple tools that are grouped together based upon function, common use case, organization, or discoverability.  Most current MCP servers have a flat namespace of tools.

I've created a repo with a small set of classes, based upon the mcp-java-sdk and the mcp-annotations projects, that supports the dynamic adding and removing of tool groups from mcp servers.

In environments with the OSGi service registry, this allows the easy, dynamic, and secure (type safe) adding and removing of OSGi services (and/or remote services) to MCP servers.

Building MCP Servers: Alternative Transports

Many developers are creating their own MCP Servers, to integrate their applications and APIs with AI models in a consistent way across multiple models.

The MCP SDKs currently provide two transports:  stdio (standard io), and http sse.  

I've created a new open source repo for alternative mcp transports.  

The intention is to provide alternative transports with other hardware, security, and trust properties.  

The first instance is based upon Unix Domain Sockets, which restricts the inter-process communication to processes running on the same operating system.

Building MCP Servers: Preventing AI Monopolies

I recently read an insightful article about using open protocols (MCP in this case) to prevent user context/data lock-in at the AI application layer:

Open Protocols Can Prevent AI Monopolies

In the spirit of this article, I've decided to make an initial code contribution to the MCP java sdk project