feat(mcp-registry): add MCP Registry metadata and server manifest #584
+76
−2
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,68 @@ | ||
| { | ||
| "$schema": "https://static.modelcontextprotocol.io/schemas/2025-10-17/server.schema.json", | ||
| "name": "io.github.containers/kubernetes-mcp-server", | ||
| "description": "A Model Context Protocol (MCP) server for Kubernetes and OpenShift", | ||
| "status": "active", | ||
| "repository": { | ||
| "url": "https://github.com/containers/kubernetes-mcp-server", | ||
| "source": "github" | ||
| }, | ||
| "version": "0.0.0", | ||
| "packages": [ | ||
| { | ||
| "registryType": "npm", | ||
| "registryBaseUrl": "https://registry.npmjs.org", | ||
| "identifier": "kubernetes-mcp-server", | ||
| "version": "0.0.0", | ||
| "transport": { | ||
| "type": "stdio" | ||
| } | ||
| }, | ||
| { | ||
| "registryType": "pypi", | ||
| "registryBaseUrl": "https://pypi.org", | ||
| "identifier": "kubernetes-mcp-server", | ||
| "version": "0.0.0", | ||
|
Comment on lines
+16
to
+25
Collaborator
There was a problem hiding this comment. @manusa should these be the same version as our most recent release? or is the idea to replace that version somewhere else?
Member
Author
There was a problem hiding this comment. This is reflected in the issue:
The idea is that the pipeline will replace the value with the tagged version (similar to what's done for the wrapper python and npm packages). This way there's no need to keep updating the version for each release. |
||
| "runtimeHint": "uvx", | ||
| "transport": { | ||
| "type": "stdio" | ||
| } | ||
| }, | ||
| { | ||
| "registryType": "oci", | ||
| "identifier": "quay.io/containers/kubernetes_mcp_server:0.0.0", | ||
| "version": "0.0.0", | ||
| "runtimeHint": "docker", | ||
| "runtimeArguments": [ | ||
| { | ||
| "type": "named", | ||
| "name": "-v", | ||
| "description": "Volume mount for kubeconfig access (host_path:container_path)", | ||
| "format": "string", | ||
| "isRequired": true, | ||
| "placeholder": "~/.kube/config:/kubeconfig:ro" | ||
| }, | ||
| { | ||
| "type": "named", | ||
| "name": "-e", | ||
| "description": "Environment variable to set the kubeconfig path inside the container", | ||
| "format": "string", | ||
| "isRequired": true, | ||
| "default": "KUBECONFIG=/kubeconfig" | ||
| }, | ||
| { | ||
| "type": "named", | ||
| "name": "-p", | ||
| "description": "Port mapping for MCP server HTTP endpoint (host_port:container_port)", | ||
| "format": "string", | ||
| "isRequired": true, | ||
| "default": "8080:8080" | ||
| } | ||
| ], | ||
| "transport": { | ||
| "type": "streamable-http", | ||
| "url": "http://localhost:8080/mcp" | ||
| } | ||
| } | ||
| ] | ||
| } | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Maybe also include the OCI package type here? https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/package-types.mdx#dockeroci-images
Uh oh!
There was an error while loading. Please reload this page.
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.
Noticing that this will require us to ensure that we label our image correctly:
LABEL io.modelcontextprotocol.server.name="io.github.username/kubernetes-manager-mcp"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 problem with this one is that you'll need to add the volume mounts to the local kubeconfig or add extra configuration so that the MCP is functional.
I'm not sure how'd this work in the scope of the registry and the consumer MCP Hosts.
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.
Yeah that's a good point - maybe we can upstream this question to the registry itself? Seems like a reasonable use case
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 added the LABEL to the container file since this PR is mostly to cover the prerequisites to be able to publish the processed
server.json.The issue will remain open until the publishing is complete.
This will also require removing a v1.0.0 of the MCP server that was published by accident: modelcontextprotocol/registry#104
Maybe that's something to try.
However, this is a particular case for MCP servers such as ours which rely on local files to automatically set up their configuration.
The other (and less powerful) Kubernetes MCP server has a hard requirement on a kubecontext file or passing its content through an environment variable.
In the Docker MCP hub there's a note at the end on how to use the MCP server:
https://hub.docker.com/mcp/server/kubernetes/overview
What I see is that by providing the 3 options, some clients might opt to use the container package (which is the safest) which won't work in most cases.
My concern is that these users might be driven away from the MCP server which essentially defeats the purpose of having it published in a registry.
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's a good point. For now let's stick with not using the OCI package then, but ideally we should find a way (perhaps with the upstream registry folks) to specify this config.
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.
Yes, this is required for the upstream repo.
@rdimitrov will this also be part of ToolHive registry validations? (e.g. stacklok/toolhive-registry-server#265)
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.
Are you planning to deploy it locally or in-cluster?
In the latter case, I image it uses the in-cluster config, right?
For those deploying the local server, you could specify the config either as an env variable:
or using the
--kubeconfigoption:In both cases the
-vis requested as apackageArguments.I hope it is clear that the registry only exposes the server metadata, and it's the admin responsibility to deploy it according to the provided instructions (e.g. start a docker container or a K8s Deployment).
The Anthropic registry is immutable, so you can't add the "remotes" field to the registered server after deployment. Instead, once deployed with ToolHive as an MCPServer instance, it will be automatically discovered by the ToolHive registry and the endpoint published to be consumed:
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.
Thanks for the detailed information ❤️
Here I'm only considering the local deployment scenario.
For in-cluster, we already provide Helm charts and other docs. In fact, the challenge for in-cluster deployment is mostly about exposing the MCP server in a secure way.
All comments refer to local deployment.
Yes, that's why I have the concern with the container image package.
The goal is that users can use the registry to discover the MCP server and are able to run it flawlessly.
With the NPM and Python package wrappers, we know for certain that if the user has a kubeconfig file, it will work straight away.
However, for the container image deployment, the volume and kubeconfig CLI flags will need to be set.
I think that if we add the suggested packageArguments, at least users will be aware that they need some extra-config to make things work.
I'm not sure of how clients (MCP Hosts) decide on the packages precedence when setting up an MCP server for a user from the registry. Maybe this is also something to consider registry-wise.