-
Notifications
You must be signed in to change notification settings - Fork 289
feat!: add toolset versioning #639
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
base: main
Are you sure you want to change the base?
Changes from all commits
6208cbd
662ad9a
4b25711
a352a85
9da490f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,53 @@ | ||
| # Toolset Versioning | ||
|
|
||
| This document describes how toolsets are versioned, the rules for toolsets changing versions, and how to configure which | ||
| tools/toolsets should be used through their versions. | ||
|
|
||
| ## How Toolsets and Tools are Versioned | ||
|
|
||
| All tools/prompts and toolsets are versioned as one of "alpha", "beta", or "ga"/"stable". Each toolset has a default version | ||
| for the toolset, however individual tools/prompts may have their own versions. For example, a toolset as a whole may be in beta, | ||
| however a newly added tool in that toolset may only be in alpha. | ||
|
|
||
| The general idea for these versions is: | ||
| - "alpha": the toolset is not guaranteed to work well | ||
| - "beta": the toolset is not guaranteed to work well, but we are evaluating how well it works | ||
| - "stable": the toolset works well, and we are evaluating how well it works to avoid regressions | ||
|
|
||
| ## Rules for Tool/Prompt/Toolset Versioning | ||
|
|
||
| Below are the criteria for the versioning of every tool/prompt/toolset. | ||
|
|
||
| ### Alpha | ||
|
|
||
| All tools/prompts/toolsets begin in "alpha". If you are contributing a new tool/prompt/toolset, this is the version to set. | ||
| There are no minimum requirements for something to be considered alpha, apart from the code getting merged. | ||
|
|
||
| ### Beta | ||
|
|
||
| For a tool/prompt/toolset to enter into "beta", we require that there are eval scenarios. For a toolset to enter "beta", there must be scenarios | ||
| excercising all of the tools and prompts in the toolset. For individual tools and prompts to enter "beta", we only require an eval scenario | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. perhaps would be good to eventually point to concrete example for that. But generally I like the requirement of having some sort of eval (w/ our toolkit)
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. type |
||
| for the specific tool or prompt. | ||
|
|
||
| **Note**: for beta we do not require that all the eval scenarios are passing - we just require that they exist. | ||
|
|
||
| ### GA/Stable | ||
|
|
||
| For a tool/prompt/toolset to enter into "stable", we require that 95% or more of the eval scenarios are passing. There is the same requirements as "beta" in terms of the number of evaluation scenarios. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 95% comes from?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think @mrunalp was mentioning this as a threshold |
||
|
|
||
| ## Configuring tools/toolsets on the server by their version | ||
|
|
||
| When configuring the MCP server, you can set a default toolset version to use for all tools with the `default_toolset_version` key. | ||
| Within all the toolsets you enable, only the tools which meet this minimum version will be enabled. For example, if a toolset has | ||
| both "alpha" and "beta" tools and you enable only "beta" tools on the toolset, you will not see any of the "alpha" tools. | ||
|
|
||
| You can also enable specific minimum versions for specific toolsets using the "toolset:version" syntax when enabling the toolset. | ||
| For example, if you want to allow all the "alpha" tools in the "core" toolset, you could set `toolsets = [ "core:alpha" ]`, and this would | ||
| enable all alpha+ tools in the core toolset. | ||
|
|
||
| See a full config example below: | ||
| ```toml | ||
| default_toolset_version = "beta" | ||
|
|
||
| toolsets = [ "core", "config", "helm:alpha" ] | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like this schema |
||
| ``` | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,16 +3,46 @@ package api | |
| import ( | ||
| "context" | ||
| "encoding/json" | ||
| "fmt" | ||
| "strings" | ||
|
|
||
| "github.com/containers/kubernetes-mcp-server/pkg/output" | ||
| "github.com/google/jsonschema-go/jsonschema" | ||
| ) | ||
|
|
||
| type Version int | ||
|
|
||
| const ( | ||
| VersionUnknown Version = iota | ||
| VersionAlpha | ||
| VersionBeta | ||
| VersionGA | ||
| ) | ||
|
|
||
| func (v *Version) UnmarshalText(text []byte) error { | ||
| var tmp Version | ||
| switch strings.ToLower(string(text)) { | ||
| case "alpha": | ||
| tmp = VersionAlpha | ||
| case "beta": | ||
| tmp = VersionBeta | ||
| case "ga", "", "stable": | ||
| tmp = VersionGA | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. minor issue:
it silently becomes VersionGA instead of the default of |
||
| default: | ||
| return fmt.Errorf("unknown version '%s': must be one of 'alpha', 'beta', 'stable', 'ga'", text) | ||
| } | ||
|
|
||
| *v = tmp | ||
|
|
||
| return nil | ||
| } | ||
|
|
||
| type ServerTool struct { | ||
| Tool Tool | ||
| Handler ToolHandlerFunc | ||
| ClusterAware *bool | ||
| TargetListProvider *bool | ||
| Version *Version // Optional version - defaults to toolset version if not set | ||
| } | ||
|
|
||
| // IsClusterAware indicates whether the tool can accept a "cluster" or "context" parameter | ||
|
|
@@ -46,6 +76,9 @@ type Toolset interface { | |
| // GetPrompts returns the prompts provided by this toolset. | ||
| // Returns nil if the toolset doesn't provide any prompts. | ||
| GetPrompts() []ServerPrompt | ||
| // GetVersion returns the version of the toolset. | ||
| // This version can be overridden by specific tools/prompts (e.g. a toolset may be beta, but have an alpha tool). | ||
| GetVersion() Version | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. for downstreaming impls we would than just set those? |
||
| } | ||
|
|
||
| type ToolCallRequest interface { | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -86,6 +86,9 @@ type StaticConfig struct { | |
| // This can be used to provide specific instructions on how the client should use the server | ||
| ServerInstructions string `toml:"server_instructions,omitempty"` | ||
|
|
||
| // Which toolset version to enable (any tools/toolsets below this will be disabled) | ||
| DefaultToolsetVersion api.Version `toml:"default_toolset_version"` | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, at "server level", we say what about explicit enablement - given a "global default" ? E.g. something like
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO there are two parts to configuring everything:
So, if you set "core", "config", and "helm:alpha" in the current setup, what would happen is:
I wasn't 100% convinced that the way I wrote it is the most intuititive, I just want to capture somewhere that there are those two key separate ideas in the config (which toolsets/domains, which versions you are okay with). My main thought is that enabling "stable" or "beta" should not enable all the toolsets with that version |
||
|
|
||
| // Internal: parsed provider configs (not exposed to TOML package) | ||
| parsedClusterProviderConfigs map[string]api.ExtendedConfig | ||
| // Internal: parsed toolset configs (not exposed to TOML package) | ||
|
|
||
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.
stable: this reads (b/c of evaluating) not that stable. that sentence reads a bit vague.