-
Notifications
You must be signed in to change notification settings - Fork 121
refactor(toolsets): renamed Profile to Toolset #309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
2da486c
to
935d05c
Compare
As a prior step to providing support for toolsets this change repurposes the current work in profiles which partially aligns with the toolsets expected features Signed-off-by: Marc Nuri <[email protected]>
935d05c
to
5c42009
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. None of my comments are blockers.
cmd.Flags().IntVar(&o.SSEPort, "sse-port", o.SSEPort, "Start a SSE server on the specified port") | ||
cmd.Flag("sse-port").Deprecated = "Use --port instead" | ||
cmd.Flags().IntVar(&o.HttpPort, "http-port", o.HttpPort, "Start a streamable HTTP server on the specified port") | ||
cmd.Flag("http-port").Deprecated = "Use --port instead" | ||
cmd.Flags().StringVar(&o.Port, "port", o.Port, "Start a streamable HTTP and SSE HTTP server on the specified port (e.g. 8080)") | ||
cmd.Flags().StringVar(&o.SSEBaseUrl, "sse-base-url", o.SSEBaseUrl, "SSE public base URL to use when sending the endpoint message (e.g. https://example.com)") | ||
cmd.Flags().StringVar(&o.Kubeconfig, "kubeconfig", o.Kubeconfig, "Path to the kubeconfig file to use for authentication") | ||
cmd.Flags().StringVar(&o.Profile, "profile", o.Profile, "MCP profile to use (one of: "+strings.Join(mcp.ProfileNames, ", ")+")") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If kubernetes-mcp-server was GA'ed, we need to first deprecate this flag to not cause any breakages. However, I think we are fine to update the flag name now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't deprecate it because as of now, the flag was useless.
It wasn't strictly no-op, but since there was just a profile, it had no effect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is fine. But from the user's perspective kubernetes-mcp-server --profile=invalid
was working but now it starts failing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that should not be working in v0.0.49.
Running the command should print the validation error and an exit 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$ npx -y kubernetes-mcp-server@latest --profile=invalid
Error: invalid profile name: invalid, valid names are: full
Usage:
...
@@ -107,15 +107,15 @@ func NewMCPServer(streams genericiooptions.IOStreams) *cobra.Command { | |||
|
|||
cmd.Flags().BoolVar(&o.Version, "version", o.Version, "Print version information and quit") | |||
cmd.Flags().IntVar(&o.LogLevel, "log-level", o.LogLevel, "Set the log level (from 0 to 9)") | |||
cmd.Flags().StringVar(&o.ConfigPath, "config", o.ConfigPath, "Path of the config file. Each profile has its set of defaults.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The removal of this statement is to fix the ambiguity or due to a behavior change in profiles/toolsets?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I envisioned profiles, it was not only about tool and prompt groups but also about default settings for other MCP behaviors.
I never implemented that, and I don't think providing defaults is part of what we want from the toolsets feature.
I'm just removing it because it's setting inaccurate expectations and is also unrelated to config.
type Toolset interface { | ||
GetName() string | ||
GetDescription() string | ||
GetTools(s *Server) []server.ServerTool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how can we achieve go-sdk transition by using server.ServerTool
but I trust your judgments. (This is independent from this PR, as there is no actual change)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll see in the follow up PRs.
The idea is to eventually make the toolset definition agnostic of the underlying MCP implementation.
This will actually be much easier with go-sdk, but I still want to do it with the m3labs implementation to be able to have a working snapshot in case there's something wrong with go-sdk and we need to revert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me. Thanks.
As a prior step to providing support for toolsets
this change repurposes the current work in profiles which partially aligns with the toolsets expected features
/cc @mrunalp @ardaguclu