[Kubernetes MCPRegistry] Expose deployed and registered servers as remote servers
Remote Servers
- Using
thvschema for now - Validate existing behavior (unit and e2e tests)
- Watch deployed servers (e.g.,
MCPServer) and register matching servers as remote servers- Store data in separate storage and then merge in
/v0/servers/and/v0/servers/deployed?
- Store data in separate storage and then merge in
Not sure if we want to use the word remote servers here given the fact there is such a think as MCPRemoteProxy in reference to remote servers.
The goal is to advertise these deployed servers using the Anthropic Registry remotes definition, there's way to name it differently if we want to match the standard:
{
"server": {
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-09-16/server.schema.json",
"name": "ai.smithery/saidsef-mcp-github-pr-issue-analyser",
...
"remotes": [
{
"type": "streamable-http",
"url": "https://server.smithery.ai/@saidsef/mcp-github-pr-issue-analyser/mcp",
"headers": [
{
"description": "Bearer token for Smithery authentication",
"value": "Bearer {smithery_api_key}",
"name": "Authorization"
}
]
}
]
},
..
}
MCPRemoteProxy is a ToolHive operator term and it doesn't fit well in this space (of course, implementation-wise the endpoint could be implemented by such a resource, but that's a detail here)
advertising MCPServers without any flag to opt in/out is kinda tricky. I rather have a flag or a way to opt in via annotations which is what i'd expect when operating a cluster. There are cases where I'm not ready to expose an MCPServer even if I've deployed it.
advertising MCPServers without any flag to opt in/out is kinda tricky. I rather have a flag or a way to opt in via annotations which is what i'd expect when operating a cluster. There are cases where I'm not ready to expose an MCPServer even if I've deployed it.
of course labels/annotations must be used to identify the target registry. the original proposal of Sept 4 defined the matching labels