Building MCP Servers - part 3: Security

There have been recent reports of critical security vulnerabilities on the mcp-remote project, and the mcp inspector project.

I do not know all the technical details of the exploits, but it appears to me that in both cases it has to do vulnerabilities introduced by the MCP Server implementation. and use of the stdio MCP transport.

I want to emphasize that example described in these two posts

Integration via Remote Tools

Example Using Remote Services

is using mechanisms that are...though heavy usage by commercial server technologies over the past 10 years...not subject to the same sorts of remote vulnerabilities seen by the mcp-remote and mcp-inspector projects.   

Also, the flexibility in discovery and distribution provided by the RSA Specification and the RSA implementation used, allows for addressing MCP Server remote tools, or protocol weaknesses, quickly and easily, without having to update the MCP Server or tooling implementation code.  

 

 

 

Building MCP Servers - part 2: Example Using Remote Services and Bndtools

In a previous post, I described how using dynamic remote tools could make building MCP Servers more flexible, more secure, and more scalable.  In this post, I show an example MCP Server that uses remote services and Bndtools to build.

To use/try this example yourself see Installing Bndtools with Remote Services Support below.

Create a Bndtools Workspace via File->New->Bndtools Workspace, and choose the ECF/bndtools.workspace template from this dialog

Choose Next->Finish

Choose File->New->Bnd OSGi Project to show this dialog

There are 4 project templates.  They should each be created in your workspace in turn:

1. MCP ArithmeticTools API Project  (example name: org.test.api)

2. MCP ArithmeticTools Impl Server Project (ArimethicTools RS Server) (example name: org.test.impl)

3. MCP ArithmeticTools Consumer Project (MCP Server Impl/ArithmeticTools Consumer) (example name: org.test.mcpserver)

4. MCP ArithmeticTools Test Client Project (MCP Client) (example name: org.test.mcpclient)

Note:  For the Impl/Consumer/Test Client project creations you will be prompted to provide the name of the project that you specified for the API Project (1)

Click Finish for each of the first 3 (server) projects.

If you wish to use your own MCP Client, and start the MCP Server (MCP ArithmeticTools Consumer Project) from your own MCP Client (stdio transport), see the Readme.md in the MCP ArithmeticTools Consumer project.

MCP ArithmeticTools Example Test Client

There is also a MCP Example Test Client Project template, implemented via the MCP Java SDK that makes a couple of test calls to the MCP Server/Arithmetic Tools Consumer server.

Note:  When creating the test client, the project template will as for you to specify the names of the API project (1) and the MCP Server/ArithmeticTools Consumer project (3).   For example:

Click Finish

You should have these four projects in the Bndtools Explorer

You can open source for any/all the projects, set breakpoints, etc.

Launching the ArithmeticTools Remote Service Impl server

The ArithmeticTools Impl server (2) must be launched first

To launch the ArithmeticTools Impl (2), see the Readme.md in that project

Launching MCP Client and MCP Server (with stdio transport)

The MCP Client (4) may then be launched, and it will launch the MCP Server (3) and use the MCP stdio transport.   The MCP Client (4) Readme.md more info on launch and expected output of the MCP Client.

You may examine or set breakpoints in the ArithmeticTools Impl Server (2) or the MCP Client (4) to examine the communication sequence for calling the ArithmeticTools.add or multiple tools.

Installing Bndtools with Remote Services Support

1. Install Bndtools 7.1 

2. Add ECF Latest Update site to Eclipse install with URL: https://download.eclipse.org/rt/ecf/latest/site.p2

3. Install Feature:  SDK for Bndtools 7.1+

Building MCP Servers: Integration via Remote Tools

It has become popular to build Model Context Protocol Servers.  This makes a lot of sense from the developer-as-integrator point of view, since the MCP specification and multi-language SDKs make it possible to easily integrate resources, prompts, and tools into multiple LLMs without having to use the model-and-language-specific model APIs directly.

MCP tools spec provides a general way for LLMs to use tool meta-data (e.g. text descriptions) for the tool's required input data, behavior, and output data.  These text descriptions can then be used by the LLM...in combination with interaction with the user...to decide when and how to use the tool...i.e. to call the function and provide some output to the LLM and/or the user.

Building an MCP Server

When creating a new MCP Server, it's easiest to create the tool metadata and implement the tool functionality as part of a new MCP server implementation.   But this approach requires that every new tool (or integration with existing API/servers) results in a new MCP server or an update/new version of an existing MCP server.

Remote Tools

It's frequently better architecture to decouple the meta-data declaration and implementation of a given tool from the MCP Server itself, and allow the MCP Server to dynamically add/remove tools at runtime, as tools can then be discovered, added, meta-data made available to the model(s), called, evaluated, and potentially removed or updated without the creation of an entirely new MCP Server, but rather dynamically discovering, securing, importing, using, evaluating, updating, and removing tools from an MCP Server.  

This approach is potentially more secure (as it allows tool-specific authentication and access control), more flexible, and more scalable, since remote tools can be distributed on multiple hosts over a network.  And it allows easy integration with existing APIs.

In the next post I describe a working example that uses remote tools.