Opinion on having multiple servers for GitHub

[rajbos]

Hi, I wanted to reach out to have get a view on how large these servers could/should become if you look at the massive amount of different API areas GitHub has. Currently it is possible to disable tools one by one, and that is it.

I previously also started the request here: modelcontextprotocol/servers#1125

My concern is that if we add every single part of the GitHub API into one server, users end up with a very large set of tools that could run. This also makes it harder for the client to choose which tool to run, as there could be multiple options for the same tool/command.

I can imagine a sort of grouping to appear on the tools in the spec at the future, giving users more fine grained access.

So giving users several servers to match only the parts of the API that they need/use, seems like a sensible thing to me. Why would I have tools available in my client for things like GHAS if I don’t use it or don’t have a license?

That’s why I separated a GHAS server https://github.com/rajbos/ghas-mcp-server as a start, to first have a discussion if this should be inside a single server or not. (I can always contribute it back into the official server).

I’d prefer if there is an official server for this by the way, it should be owned and supported by the vendor in my opinion.

So how do you see having a massive MCP server like for GitHub with everything and the kitchen sink in it, vs smaller servers that would mean more maintenance and configuration for the end user?

[almostwhitehat]

👋 I have a prototype for exactly this at almostwhitehat#1 - feedback would be great!

[SamMorrowDrums]

#189 @almostwhitehat that tool level filtering suggestion is very interesting. You are encouraged to share that on this RFC issue too.

I think tool level is a great option, although I'm curious if that should be configured by the host or on the server as proposed. Thank you for taking the time to write that up!

The proposal I am currently working on is for broader grouping by product/feature. As GitHub has a lot, it seems like individual tools could eventually be a really long list to specify individually.

These two approaches could perhaps combine quite well too.

[SamMorrowDrums]

Hi I am going to close this, but I would love feedback on: #275

In the v0.2.0 release we allow you to start the server with pre-specified toolsets, or use dynamic tool discovery to prevent issues of having extreme numbers of tools. Hopefully this resolves your issue.