MCP Joins the Linux Foundation

 

MCP Joins the Linux Foundation

AI and an Architecture of Open Source Participation

 A perspective on open source participation and AI:  

What MCP and Claude Skills Tell Us About Open Source For AI

Foundation Announces Maintainers Fund

 Rust Foundation Announces Maintainers Fund

History

 

Why I Gave the WWW away for Free by Tim Berners-Lee

Building MCP Servers: Tool Descriptions + Service Contracts = Dynamic Tool Groups

The Model Context Protocol (MCP) can easily be used to expose APIs and services in the form of MCP tools...i.e. functions/methods that can take input, perform some actions based upon that input, and produce output, without specifying a particular language or runtime.

OSGi Services (and Remote Services) provide a dynamic, flexible, secure environment for microservices, with clear well-established mechanisms for separating service contracts from service implementations.

One way to think of a service contract for large language models (LLMs) is that the service contract can be enhanced to provide LLM-processable metadata for each tool/method/function.  Any service contract can still be used by human developers (API consumers), but with tool-specific meta-data/descriptions added, larger service contracts can be also used by any model.

Since service contracts in most languages are sets of functions/methods, the service contract can also be used to represent groupings of MCP tools, or Dynamic MCP ToolGroups.   The example on the MCPToolGroups page and on the Bndtools project templates, is a simple example of grouping a set of related functions/methods into a service contract and including MCP tool meta-data (tool and tool param text descriptions).

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.