Make MCP dynamic capable of discovering available resources and MCP tool mapping

[gianarb]

I think we should take inspiration from the kubernetes-mcp-server https://github.com/containers/kubernetes-mcp-server/tree/main in practice it discovers dynamically the available resources, and it builds the MCP tools accordingly.
There are configuration options to skip some resources or actions if needed, we can add something similar as well as second step.

But I like the idea to remove all the code that currently makes the MCP a bit more static.

Most likely this will break some of the definitions we have today because those are manually written, the one we will have are derived from the resource description and things like that.

But it looks a lot easier to maintain long term. I am expecting less code, and it adapts based on server capabilities.

I would also like to reuse the auth client package in datumctl, so the authentication behaves in the same way (not 100% sure how it looks like, but that's the idea). The current auth package in datumctl has some limitations (it does not support token override I think), but the idea is to make those to get better together so we can offer the same experience. If you like the approach I can try and see where we end up (edited). In the end we want to embed the MCP as part of the CTL so it makes sense for authentication to be the same.

/cc @scotwells @zachsmith1

[scotwells]

Leveraging API discovery was something we evaluated before. I believe @zachsmith1 had concerns about how much context this would consume as the number of APIs grows. Maybe there's still value in having it available as a tool for discovery / research around how to use Datum Cloud? We could also consider an opt-in approach where users can decide to enable discovery in the toolset.

For authentication, I wonder if we should take a similar approach that we took with datumctl where the MCP server should accept a factory that datumctl provides for wiring up authentication? That should allow us to embed this cleanly.

[gianarb]

had concerns about how much context this would consume as the number of APIs grows.

Sorry not an expert here. The concern is that the MCP will have so many tools that it will be used for too many things during the conversation? What I like about how kubernetes-mcp work is that you don't need to change it if the server changes by default it works because it reads a list of resources and figure out how to register them properly. It looks like the code will be a lot easier to maintain. The kubernetes-mcp has two configurations one to discard tools (k8s resources) and another list to declare the one allowed. I think they did that because they shared the same concerns @zachsmith1 has. So I am wondering if we should do the same thing so we get an easier to maintain codebase that adapts itself + we leave the user to configure what they want. As a user onboarding the MCP I am expecting it to be capable to interact with all the resources, I think we should avoid something like "domains are not yet implemented" because we did not update the MCP. For more advanced users I think having the options to decide what to discard or allow makes total sense

For authentication, I wonder if we should take a similar approach that we took with datumctl where the MCP server should accept a factory that datumctl provides for wiring up authentication? That should allow us to embed this cleanly.

Yep I think that's what I was trying to say. I would like to reuse as mush as possible the underline packages that datumctl has like client and auth. Not sure how it will look at the end up but I think it is a nice try

[zachsmith1]

Totally agree we should simplify and optimize. I think the main concerns I have are 1) number of tools we expose and 2) context generated per tool. After too many tools, LLMs get bad at picking correctly over time and when context grows. I think there are also some limits around response size per tool call that some providers implement. When I was running the naive project listing it was cutting off a few of my projects as an example.

I think we should think about the concepts we want to expose out of our MCP because the K8s MCP in theory is what users should be using if they want the full nuts and bolts experience.

In terms of re-use, I did copy over a good chunk of the auth/client logic but deviated a bit. would be nice to pull in a pkg that just worked

[gianarb]

I think I see what you are saying. The risk of getting an easy remap from kube dynamic identified resources is the experience not being nice and to overlap with what kubernetes-mcp is does. I don't think Datum user can use kubernetes-mcp because project/organization but I am not sure about it.

I think we should think about the concepts we want to expose out of our MCP

As far as today I don't think I have enough MCP experience or Datum experience to really figure it out.

I will reach out to @jacobsmith928 I think here maybe he can help us navigate this situation? I am also reading a lot of articles about MCP and some says that it won't survive for much long, or that a good SDK can be a solid replacement? Don't know I am digging into the topic!