modelcontextprotocol
Add Google Artifact Registry as docker registry
Is your feature request related to a problem? Please describe. Our server is deployed in GAR. As of now, it seems like MCP registry only supports the official Docker registry.
Describe the solution you'd like Supporting GAR.
"registry_type": "oci",
"registry_base_url": "https://artifactregistry.googleapis.com",
"identifier": "<region>-docker.pkg.dev/<repo>/...",
"version": "1.0.0",
"file_sha256": "filesha256",
"tag": "latest", // it will be great to support tag as well.
Describe alternatives you've considered N/A
Additional context N/A
Sounds good! Same probably applies as for GHCR here: https://github.com/modelcontextprotocol/registry/issues/393
I've added support for Google Artifact Registry (GAR) in PR #485, which includes 15 major OCI registries in total.
Note: While I couldn't test against actual GAR instances, I've implemented comprehensive mock-based tests that simulate GAR's API behavior including:
- Support for regional endpoints (e.g.,
us-west1-docker.pkg.dev) - Anonymous pulls for public images
- Proper error handling
The implementation is based on GAR's API documentation and follows the same patterns as Docker Hub. Real-world testing by someone with GAR access would be very helpful to validate the implementation.
@domdomegg I saw that one of the OCI requirement is to use Auth URL. afaik, GAR does not take AuthURL to generate auth. Instead, we use service account to ensure that the client have access to the service (by using a service account key), or user can generate a temporary OAuth access token to authenticate with GAR (ref: https://cloud.google.com/artifact-registry/docs/docker/authentication).
How will the existing OCI implementation work with this? What would you recommend?
I'm not super familiar with how Google Artifact Registry does auth, but my guess is we'd want some form of ether anonymous auth, or can create a service account for registry if one is really needed. It looks like Artifact Registry supports this with allUsers, although I don't know how clients are supposed to pull.
Do you have an example image identifier I can use to test this? E.g. the one for your MCP server you intended to publish?
@Yuan325 - hey, I'll check further but I feel that should be easily achievable (assuming I got it all right)
From the perspective of the registry we want all published servers to have publicly accessible packages. So with that in mind if an oci image hosted on gcr is public(you have set allUsers to the reader role) there shouldn't be any need to provide any additional authentication to access the package and its annotations(needed for the validation we do on the registry side), right?
As for the clients, my understanding is it should also work the same as other OCIs. For example a docker pull (or some other alternative) should already work.
I’ve been thinking about this more and started a thread on Discord whether we should use this opportunity to switch to a client library like go-containerregistry which would enable us support all OCI-compliant registries. I'll post a message afterwards sharing any potential decisions 👍
@domdomegg Yeap! Here's the image identifier: us-central1-docker.pkg.dev/database-toolbox/toolbox/toolbox:latest
@rdimitrov Yes, our image is in a registry that allow read from allUsers. And yes, it shouldn't need any authentication to access the image itself. Thanks for sharing the thread and the updates! greatly appreciated!
@Yuan325 - The PR adding support for GAR got merged, so if you're interested it would be nice to confirm it works for you 👍
It should be available in staging - https://staging.registry.modelcontextprotocol.io/docs