Skip to content

Conversation

manusa
Copy link
Member

@manusa manusa commented Sep 10, 2025

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

@manusa manusa added this to the 0.1.0 milestone Sep 11, 2025
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]>
Copy link
Member

@ardaguclu ardaguclu left a 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, ", ")+")")
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

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.")
Copy link
Member

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?

Copy link
Member Author

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
Copy link
Member

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)

Copy link
Member Author

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.

Copy link
Member

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.

@manusa manusa merged commit 10c82f7 into containers:main Sep 11, 2025
10 of 11 checks passed
@manusa manusa deleted the refactor/profiles branch September 11, 2025 07:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants