[Bug] Architecture proposal - Having public HTTPS endpoint that exposes our server manifest won't be secure at all

[marcpradas-IAG]

Hi,

We've been directly talking with github people but they havent been able to solve our concerns or doubts, they've send this article to us 'explaining how to setup an internal MCP registry':

https://docs.github.com/en/enterprise-cloud@latest/copilot/how-tos/administer-copilot/configure-mcp-server-access#example-registry-format

https://github.blog/changelog/2025-09-16-github-mcp-registry-the-fastest-way-to-discover-ai-tools/

And the second article is what brought me to open a bug here. I'm still worndering why do we need to add all this manifests and how authentication was going to be managed inside this ecosystem, but when solving my questions I realized of how limiting is that recipient in comparison of what we used to have...

1st question that comes to my mind: Why dont you use already existing registry technologies? Github has GHCR.io for example, what we have implemened is a way to import, scan and wrap any mcp coming from any source and put them all into a unified source, but this unified source is GHCR and as far as I can see this won't be compatible with the new registry tech that you are defining...

I saw that there is already a PR to cover GHCR compatibility: #393

Seems that its still missing automated authentication for private and internal registries and also would be nice no make Copilot agent pull the images and execute them when connecting to a private registry manifest, is it planned to be implemented?