The Model Context Protocol is a very powerful mechanism to extend the capabilities of the Claude application by easily inserting dynamic data in the context of your prompts.
After only a few weeks after the announcement, there are already tens (hundreds?) of MCP servers available:
the official list of reference servers is available here
another repository , Glama, for Open-Source MCP servers.
To install and test a MCP server is simple but requires to edit the claude_desktop_config.json file to add the command line required to start the MCP server and to restart Claude.
That’s not very difficult but if you want to test a lots of MCP servers that may become a bit tedious.
There is already a smart MCP server that allows you to add a MCP server from Claude itself.
As part of my gomcp , I am trying to do offer something a bit different to make it easier to test multiple go mcp servers at once.
The basic architecture is as follow:
In Claude you configure only one MCP server: the mutiplexer:
In each directory on your machine where there is a MCP server that you want to test, you run the command from the terminal:
Once started, the proxy will act as a MCP client and ask the characteristics of the MCP server and then relay them to the Multiplexer.
From the MCP client perspective (eg. Claude), there will be only one MCP server with potentially a lot of tools/prompts/resources exposed.
The proxy and multiplexer will be connected through a local socket connection and if the client calls a tool, the multiplexer will redirect that call to the proper proxy and the response will be sent back to the client.
A simplified sequence diagram is:
Status
I have a working prototype but this is very much an alpha version.
After a npm install, the way to start this MCP server is to run: node dist/index.js.
To proxy that server you then simply run:
The proxy will get the list of tools that the MCP server supports and store that list in a shared directory with the multiplexer.
It will then wait for the multiplexer to start (see the next section for the reason for that behavior).
As soon as the the multiplexer starts, meaning here when Claude starts, the proxy connects to that multiplexer and registered itself.
From Claude, you ask to take screenshot:
As usual, Claude will ask for permission. Even though the function puppeteer_navigate is implemented by the Puppeteer MCP server, from Claude’s perspective, this tool is available with the gomcp server.
The proxy and the hub work together to call the function on the Puppeteer server and relay the response back to Claude:
Limitations
For now, the proxy only manages the tools, not the prompts nor the resources.
Even though the protocol supports the possibility to report change in the list of tools it appears that Claude does not support that.
That means that we can’t start a new proxy once Claude have been started: even though the proxy will report the tools it supports, Clude on’t be aware of them before a restart.
To make that process less painful, the proxy records its tools in the ~/.gomcp directory.
That means that you can start the proxy before the multiplexer is started (and so, before Claude is started).
Implementation details
When the proxy starts, it creates a local file:
This file contains a generated proxy_id that is used to identify itself with the multiplexer.
We also store the command line arguments: next time you want to run the proxy, you just run gomcp-proxy (no argument), the proxy will know how to start the MCP server.
You can also have a .env file if you need to make some environment variables available for the MCP server.
The proxy will also create a file shared with the multiplexer at: $HOME/.gomcp/proxy_tools/0d49e877-ec73-459a-b36f-195d34260092.json
This file contains the tools that the MCP server exposed:
This file will be used by the multiplexer when the MCP client will ask for the list of tools.
Future evolution
Eventually, the server will be able to start the proxy, with their MCP server, on demand when a tool/prompt/resource request is coming from the MCP client for that proxy…
There won’t be anymore reason to start all the proxies ahead of time.
Cleanup
Once you don’t want to use a given MCP server as a proxy, you can easily delete all its proxy related files with:
When Claude restarts, it won’t be aware anymore of that MCP server or its tools.