Skip to content

Publish solr-mcp to the official MCP Registry and the Docker MCP Catalog with the 1.0.0 release #251

Open

Description

@adityamparikh

Status: needs a PMC member and Infra. Blocked on a passing 1.0.0 vote: the dev@ votes ended FAILED on 2026-05-05 and CANCELLED on 2026-06-21, and none has been called since (dev@ archive, 2026-10-12). The repo-side fixes to server.json and release-publish.yml are specified in #261, and PR #263 implements them. PR #259 fixes the SBOM path that stops publish-docker. Unverified: whether the INFRA ticket is filed. None is linked from #251, Jira search needs a login, and hub.docker.com/v2/repositories/apache/solr-mcp/ returns 404 on 2026-10-12.
Size: S — an INFRA ticket, one job re-run, and one YAML PR to docker/mcp-registry.

Problem

release-publish.yml has a publish-mcp-registry job, but three things outside the code stop it from listing 1.0.0:

  1. There is no Docker Hub repository apache/solr-mcp, and the repo has no Docker Hub secrets. Infra provisions both.
  2. A new GHCR package is private. The registry pulls each OCI image anonymously and rejects a private one with "OCI image '…' is private or requires authentication" (oci.go, remote.WithAuth(authn.Anonymous)). Changing the visibility of a package in the apache org needs Infra.
  3. The workflow must run before the registry job can, and it fails today. publish-docker reads the SBOM from the pre-3.x path, so it fails after pushing the images. publish-mcp-registry needs publish-docker, so it never runs (release-publish.yml:261, :274, :520). PR ci: read the SBOM from build/reports/cyclonedx/ #259 fixes this. The server.json and workflow defects that the registry would reject are listed in Publish 1.0.0 to the official MCP Registry from the ATR release: server.json and release-publish.yml fixes #261.

The Docker MCP Catalog does not read the official registry. It needs its own PR to docker/mcp-registry.

Proposal

Order

  1. Merge ci: read the SBOM from build/reports/cyclonedx/ #259 and ci(release): publish voted releases to the official MCP Registry #263 (Publish 1.0.0 to the official MCP Registry from the ATR release: server.json and release-publish.yml fixes #261).
  2. The 1.0.0 vote passes.
  3. Infra creates the Docker Hub repo and secrets (step 1 of the checklist below). This can happen before the vote.
  4. The release manager runs release-publish.yml. On the first release the registry job fails because the GHCR package is still private.
  5. Infra makes ghcr.io/apache/solr-mcp public, and the release manager re-runs only publish-mcp-registry.
  6. Open the docker/mcp-registry PR.

PMC and Infra checklist

  • A PMC member files an INFRA ticket that links the dev@ thread agreeing to publish images, as the Docker Hub policy asks. The ticket asks Infra to:
    • create the Docker Hub repository apache/solr-mcp;
    • add the DOCKERHUB_USER / DOCKERHUB_TOKEN secrets, the pair apache/solr reads (docker-nightly.yml);
    • make the ghcr.io/apache/solr-mcp package public after the first release push.
  • After the first release, re-run publish-mcp-registry once the package is public. Later releases push to the same package.

Namespace

Keep io.github.apache/solr-mcp. mcp-publisher login github-oidc grants io.github.<repository_owner>/* to a workflow running in an apache/* repo (github_oidc.go, buildPermissions). The job already requests id-token: write (release-publish.yml:525), so the registry login needs nothing from Infra. A DNS namespace such as org.apache.solr/solr-mcp would need a TXT record or a /.well-known/mcp-registry-auth file on solr.apache.org, plus a private key held as a secret (authentication). Infra would own both, and the image label io.modelcontextprotocol.server.name (build.gradle.kts:586) would change. Nothing in the issue asks for that.

Docker MCP Catalog (after the release)

Add servers/solr-mcp/server.yaml to docker/mcp-registry with the repo's tooling (CONTRIBUTING.md):

task create -- --category search --image apache/solr-mcp \
  https://github.com/apache/solr-mcp -e SOLR_URL=http://host.docker.internal:8983/solr/
task catalog -- solr-mcp
  • Use a self-provided image (--image), as the alfresco and maven-tools-mcp entries do. Without --image, Docker builds the image from the repo's root Dockerfile into its own mcp/ namespace. solr-mcp builds with Jib and has no Dockerfile, and a Docker-built image would sit outside the ASF release.
  • meta.category: search, the category the elasticsearch entry uses.
  • source.commit: the commit of the v1.0.0 tag.
  • config: model it on the elasticsearch entry, with SOLR_URL in env and as a required parameters property.
  • task create runs the image and lists its tools, so no tools.json is needed: over STDIO the server answers tools/list (15 tools) with SOLR_URL pointing at a closed port (checked 2026-10-12 with the JVM jar).
  • Docker reviews every PR before merging.

Implementation notes

Two release-publish.yml changes that neither #261 nor PR #263 (head 30784db2) makes. Add them there:

  • :240-244 passes the GHCR token as -Djib.to.auth.password on the command line. Move it into JIB_TO_AUTH_USERNAME / JIB_TO_AUTH_PASSWORD env, as the Docker Hub step does at :209-213.
  • :520 makes the registry job wait for publish-native-manifests, although server.json lists no native image. Whether a native build failure should hold back the registry entry is a maintainer choice. The comment at :515-516 says the wait is deliberate.

Acceptance criteria

Out of scope

File and line references are against main at 7cb39a3d.

Original description

What we want

Once 1.0.0 passes its vote, solr-mcp should be listed in:

  • The official MCP Registry (registry.modelcontextprotocol.io) as io.github.apache/solr-mcp, pointing at the release images on Docker Hub (apache/solr-mcp) and GHCR (ghcr.io/apache/solr-mcp).
  • The Docker MCP Catalog (hub.docker.com/mcp), the catalog behind Docker Desktop's MCP Toolkit, pointing at apache/solr-mcp.

Only voted releases get listed. ASF policy says projects "SHALL NOT publish unreleased materials outside the development community", so no snapshots or nightlies. release-publish.yml already publishes to the MCP Registry as part of the post-vote release.

What needs to happen on the ASF side

These steps need a PMC member and ASF Infra. Contributors can't do them.

  1. An INFRA ticket. A PMC member files an INFRA Jira ticket, linking the dev@solr.apache.org thread that agrees to publish solr-mcp images. Infra's Docker Hub policy asks for that link. The ticket asks Infra to:

    • Create the Docker Hub repository apache/solr-mcp.
    • Add the DOCKERHUB_USER / DOCKERHUB_TOKEN secrets to apache/solr-mcp. These are the names Infra provisions. apache/solr uses the same two to push apache/solr-nightly (docker-nightly.yml).
    • Make the ghcr.io/apache/solr-mcp package public after the first release push. GHCR packages are private when first published, even when pushed from Actions with GITHUB_TOKEN. The MCP Registry only accepts images it can pull anonymously. Changing a package's visibility needs admin on it, which in the apache org means Infra.
  2. A re-run on the first release. The release manager runs release-publish.yml after the vote as usual. On the first release only, the MCP Registry step fails, because the new GHCR package is still private. Once Infra has made it public, re-run that one job. Later releases push to the same package, which is public by then.

Nothing is needed from Infra for the MCP Registry login itself. The io.github.apache/* namespace is authorized through GitHub OIDC from the workflow, with no stored secret.

Contributor side

These need no ASF permissions:

  • bringing server.json up to the registry's current format and the image names the workflow actually pushes;
  • switching release-publish.yml to the secret names above;
  • the docker/mcp-registry submission, after the release.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions