An MCP Registry compliant with the specs

[dmartinol]

The MCP Registry is a

community driven registry service for Model Context Protocol (MCP) servers.

The Kubernetes operator could define an MCPRegistry resource to expose all the deployed MCPServer's using the same reference schema, to simplify the integration with clients adhering to the MCP standard.

Also, configurable labels or namespace filters could be used to define multiple registries in the same cluster.

Implementation Notes

The reference implementation fetches the server data from a MongoDB instance.
If we populate the registry collection with data generated from each deployed (and undeployed) server, we could reuse the implementation as-is and just plug the database connection.

[JAORMX]

We really want to have something like this. Unfortunately with the registry spec as it is we would loose functionality which is a non-starter. We're trying to get involved to have the possibility of defining this extra data we need.

[rdimitrov]

Thanks for reaching out, @dmartinol 👋

We’re definitely interested in supporting the upstream registry format. As @JAORMX mentioned, the main blockers at the moment are around the inability to transfer some of our metadata, i.e. the provenance information or other metadata specific to how we run MCP servers.

That said, we’re actively looking into contributing to the registry spec (cc: @tadasant) to help evolve the format and make it more universal.

Out of curiosity can you share more about your use case, i.e. are you already running the registry stack or it's something else?

[dmartinol]

We’re definitely interested in supporting the upstream registry format. As @JAORMX mentioned, the main blockers at the moment are around the inability to transfer some of our metadata, i.e. the provenance information or other metadata specific to how we run MCP servers.

We (me and @RoddieKieley) had the same concern but, until the upstream doesn't integrate any equivalent metadata, we could just avoid transferring them and define a compatible API. BTW: what about tracking an issue to the reference repo requesting to extend the schema and support the missing metadata?

What we envision is something like the following. E.g. for the reference atlassian server, the equivalent standard description could be:

  {
    "id": "XXX-YYY-ZZZ", # UUID generated at DB insert time
    "name": "atlassian",
    "description": "Connect to Atlassian products like Confluence, Jira Cloud and Server/Data deployments.",
    "repository": {
      "url": "https://github.com/sooperset/mcp-atlassian",
      "source": "github", # Guess from repository_url
      "id": "897809208" # Calculated from `curl -s "https://github.com/api/repos/sooperset/mcp-atlassian" | jq '.id'`
    },
    "version_detail": {
      "version": "latest", # From image
      "release_date": "2025-07-21T00:24:40Z",  # From /metadata/last-updated
      "is_latest": true 
    },
    "packages": [
      {
        "registry_name": "docker",
        "name": "ghcr.io/sooperset/mcp-atlassian",
        "version": "latest",
        "environment_variables": [
        {
          "description": "Confluence URL (e.g., https://your-domain.atlassian.net/wiki)",
          "name": "CONFLUENCE_URL",
          "is_required": false
        },
        {
          "description": "Confluence username/email for Cloud deployments",
          "name": "CONFLUENCE_USERNAME",
          "is_required": false
        },
...
        ]
      }
    ],
    "remotes": [
      {
        "transport_type": "sse",
        "url": "http://<SVC_NAME>:<TARGET_PORT>/sse" # One entry for each deployed MCPServer
      }
    ]
  }

Many metadata would be lost during the conversion, like all those under permissions, status, tags, tier and tools sections. For each of them an RFE issue could be tracked to the MCP repo, WDYT?

As an alternative, why don't you evaluate adopting the standard schema as-is and extend it with further metadata?

Out of curiosity can you share more about your use case, i.e. are you already running the registry stack or it's something else?

We're exploring the K8s deployments with ToolHive, which is a reasonable approach until we'll have a community standard, but for already defined interfaces like the registry, we'd like to keep it standard as much as possible.

[rdimitrov]

We (me and @RoddieKieley) had the same concern but, until the upstream doesn't integrate any equivalent metadata, we could just avoid transferring them and define a compatible API. BTW: what about tracking an issue to the reference repo requesting to extend the schema and support the missing metadata?

Yes, we already had a chat with @tadasant and are going to start a GitHub discussion in the registry repository with what it would look like if ToolHive adopts the upstream registry format. This would highlight the missing properties like the one you mentioned (permissions, status, etc.) and it would help kick off the discussion around how to solve these issues in a way that is generic enough for everyone 👍

The reference implementation fetches the server data from a MongoDB instance.
If we populate the registry collection with data generated from each deployed (and undeployed) server, we could reuse the implementation as-is and just plug the database connection.

As for the server discovery, let us think about it. I think it's probably better to have something like what you suggest with the MCPRegistry CRD or probably expose a Registry API (we already have something started for the API server implementation of toolhive but would not work for k8s as the operator uses the CLI).

[dmartinol]

I think it's probably better to have something like what you suggest with the MCPRegistry CRD or probably expose a Registry API

Yep, I meant to deploy the (REST) API as a deployment of the MCPRegistry (K8s) API.

Great to hear that you are involved with the upstream registry project. We'll be definitely glad to help: standardizing our Kubernetes implementation is key to reaching a wider client base. Thank you!