question on the docker runtime type

[benoitf]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Hi all,

While reviewing the current specification, I noticed that MCP servers can be declared using OCI images, but the type is specified as docker:

registry/docs/server-registry-api/examples.md

Line 88 in 1a6dc93

"registry_name": "docker",

Given that users may use different container runtimes (e.g., Podman, the upcoming Apple container runtime on macOS, etc.), I’m wondering how best to represent this in the registry.

Should we:

Register the same image under multiple types (e.g., docker, podman, apple-container, etc.), or

Use a more generic type like container or oci, and provide a runtime_hint field to indicate the preferred runtime (e.g., Docker, Podman, etc.)?

Curious to hear your thoughts on how this should be handled to maintain flexibility

Thanks!

[tadasant]

Actually, I think docker there is a misnomer - it should have been dockerhub. I think that's worth changing in our spec.

With that in mind, then the question is just what (if any) other container registries we want to register. GHCR is another popular one I've seen the MCP community using.

docker, podman, etc should be values in this enum:

registry/docs/server-json/registry-schema.json

Line 28 in 1a6dc93

"runtime_hint": {

which I think we wouldn't mind expanding to whatever list we feel is helpful. Only reason it's an enum and not a string is to sanitize/prevent some sort of injection attacks.

Thank you for flagging!

[benoitf]

thanks for the clarification 👍

[slimslenderslacks]

@tadasant the problem with using dockerhub is that dockerhub is just a registry (an oci compliant one). So we have different registries (eg ghcr, gcr, dockerhub, jfrog, acr) and we also have different runtimes (docker, podman, apple-container). Even if typical dockerhub users are using the docker runtime, other non-docker runtimes can still pull from dockerhub.

So we have concepts like image references registry/repository:tag or registry/reposistory@digest for different runtimes to pull these mcp server images. Dockerhub kind of got lucky (first on the block) with a lot of runtimes assuming that the default registry is "docker.io" but technically, a dockerhub mcp/server:latest is short for docker.io/mcp/server:latest.

And then we also have different runtimes but that choice might could be left up to the mcp host. "Docker" registry packages could be interpreted by the mcp host depending on which docker runtime is available.

I was just looking through some of the registry_name=docker entries in the in the seed data and many of them can't be turned into image references that could be "pulled".

I also think that declarations like environment_variables should not have to be mirrored by -e package arguments. All docker runtimes support the concept of environment variables. Volumes are trickier but they're still container concepts that can be implemented by each runtime. It's not clear to me that the owner of a package should have to care which runtime actually gets used. They need to specify how the image is being distributed (using an image reference), and whether it uses runtime arguments, and environment variables.

[slimslenderslacks]

I think it would make sense to use container or oci as suggested by @benoitf. We could then focus on oci image references for the MCP host to implement pulls. This would allow us to also focus on recommendations like using digests (instead of tags) so that packages are not updated without having to change the server version.

Some package_arguments that are common, or even mandatory, for different runtimes, could be left out of all package definitions. For example -i for stdio servers running in docker, is universally required. The --rm option to remove containers that have exited is part of the mcp host configuration, not a requirement for the mcp package. But I think we can create some best practices that would help us to keep container/oci packages usable by different runtimes.

[tadasant]

Will circle back to this conversation when I have a little more time, but I see what you all are saying; i.e. instead of enumerating dockerhub, jfrog, etc we could just do a single option container/oci, and differentiate between the registries in the name field. That makes sense to explore (does name still make sense as the key name for e.g. docker.io/mcp/server)? I worry a bit that maybe this modeling won't align well with how we're handling pypi/npm/etc?).

[tadasant]

After thinking about this a little more, I'm actually not sure we'd want to make a significant change here. There are at least two reasons it is valuable to us to be explicit about registry_name=dockerhub rather than doing something generic like package_uri=docker.io/mcp/filesystem:

• By including an explicit whitelist of well known registries, rather than an open-ended URI that could point to any (malicious) registry, we lean on existing registry standards for combatting spam and malicious code (it's one of our design principles). So someone can't go and stand up maliciousregistry.org and start hosting packages they submit all over the MCP Registry and try to inject into MCP clients.
• We still need to come up with some mechanism for validating that the references are correct (here). If we allow arbitrary references (rather than a predefined set of "trusted" registries), this might become an intractable problem

These two thoughts are actually relevant to #260 as well, since we are contemplating allowing an open-ended URL claiming to host a DXT package there... I don't love the security/spam exposure there. Though that DXT problem is even harder than the container/oci one here, since fundamentally there don't pre-exist any DXT registries we can lean on to start. What do you think @domdomegg @felixweinberger - should we just not be concerned about allowing arbitrary URLs for container/oci images and DXT packages? If not, then we lose our design principle of "leaning on established registries" -- it starts to beg the question of why not just ditch the whole "metaregistry" concept and host all the source code ourselves.

---

Responding to specifics --

the problem with using dockerhub is that dockerhub is just a registry (an oci compliant one).

I am aware that is the case, but I don't quite follow why that is a problem.

Even if typical dockerhub users are using the docker runtime, other non-docker runtimes can still pull from dockerhub.

I think that's fine. It's up to the server maintainer to make suggestions as to how their server can be run. If folks want to run them in a way that server.json didn't define (and thus surely did not test), that's up to them and I don't think we need to codify all the possible ways a server can be run (as long as a maintainer is providing some examples of recommended ways).

I was just looking through some of the registry_name=docker entries in the in the seed data and many of them can't be turned into image references that could be "pulled".

The seed data is just dummy data that hasn't been verified; everything with registry_name=docker (should be registry_name=dockerhub as per my first comment here) is meant to be pull-able via docker.io/{name}.

I also think that declarations like environment_variables should not have to be mirrored by -e package arguments. All docker runtimes support the concept of environment variables. Volumes are trickier but they're still container concepts that can be implemented by each runtime. It's not clear to me that the owner of a package should have to care which runtime actually gets used. They need to specify how the image is being distributed (using an image reference), and whether it uses runtime arguments, and environment variables.

This sounds like reasonable feedback and I think could just be convention we encourage in "how to write your server.json to support docker as a runtime" and/or any associated automated tooling we release to assist with this. Probably aligned with your last comment that re "we can create some best practices"

I think it would make sense to use container or oci as suggested by @benoitf. We could then focus on oci image references for the MCP host to implement pulls.

I'm not sure I follow -- what does using registry_name=container/oci and name=docker.io/mcp/filesystem unlock that the model of registry_name=dockerhub and name=mcp/filesystem does not? The MCP Client host would know that dockerhub is docker.io. Am I missing some nuance here for other cases?

[domdomegg]

Hmm thinking about this more, I think I would maybe be in favour of keeping docker (or container or oci), but in practice the public registry only accepts certain allowlisted hosts which are reasonably trustworthy (in the sense that they can be considered responsible for moderation, maybe docker.io, ghcr.io, quay.io).

Then people who extend the registry and have private docker registries can use the same compatible format. And we can easily extend/contract the allowable Docker registries as we get more/less confidence in them.

[tadasant]

That's fair I like how that keeps the external registry benefit in place! We might want to rethink the key names (rework registry_name, name to be something like registry_name, package_type, and package_identifier) but conceptually I could see that approach accommodating all concerns here