Request to support MCP registry

fhusson_1634

Hi,

With GitHub Copilot and MCP server we can use an url to white list MCP server.
It could me nice to have Proget as an MCP registry for this purpose.

https://docs.github.com/en/copilot/how-tos/administer-copilot/configure-mcp-server-access
https://github.com/modelcontextprotocol/registry

Regards,
Frédéric

apxltd

Hi @fhusson_1634 ,

From a quick read of the documentation, it looks like an "MCP Registry" is basically a list of "MCP Servers", which is basically a JSON document that describes.... an API or something?

What I'm not seeing are "Packages" (i.e. an archive file with a manifest file) nor a "Central Repository" (i.e. a canonical location where OSS Models are stored). If that's the case, I'll do a "hard pass" on this for the forseeable future -- there's not much value ProGet could add here and we'd have to add a completely separate, non-package subsystem like Assets or Docker.

Let me know if I misread the specs

Thanks,
Alex

fhusson_1634

Hi,

Yes from my understanding you got it right.
It's still very young.
It's about storing a json "package" or text.

In the json you can have a config for an url for a remote MCP server or a package that you can run on your computer to be a local MCP server (only from official repo for now).
Maybe in the futur if this kind of registry can validate private package it could be nice to flag a package already in inedo to make it available in the MCP registry.

Exemple :
An internal team create an npm package for a MCP server or a docker package
In proget I can have a MCP Registry with all kind of MCP server and for our own package we can just check an option on the package in proget to have it in the registry.

Regards,
Frédéric

apxltd

Hi @fhusson_1634 (and cc/ @dan.brown_0128),

We conducted some research into MCP Servers and MCP Registries (or "Metaregistries" as they are technically called). However, based that, it doesn't make sense for us to pursue at this time or likely in the future.

I'll share my (new) understanding; I don't think MCP Registries will be a thing a year or two from now.

First issues comes down to quality. If you take a look at the Official MCP Registry, you'll see it's almost entirely just a bunch of AI-generated MCP Servers published by vibe coders. This one kid basically spammed the MCP Registry with hundreds of named-mcp-utilities, which appear to be like leftpad but for slop coding.

There's just no sense in even attempting to curate MCP Servers from this mess - it's 99% rubbish on a good day. So best case scenario... you would have to point to a private MCP Registry, which are far and few between.

The major AI tools (Claude, etc) just use a curated list of plugins that do the same thing.

Second issue comes down to instability. The MCP Registry protocol has been changing quite a bit and isn't remotely stable enough to reliability aggregate or curate. Since AI agents are what's "talking" to an MCP registry, the protocol doesn't reaaaaaaaly need to be API-stable.

Finally, it's pretty much obsolete already. The "old" (i.e. few months ago) way of communicating with MCP Servers was using a streamable-http interface, where your LLM and the MCP server "chatted" over a quasi-API. But now it's done through "MCP Server" packages.

These days, your LLM agent now just "chats" using some specially-built npm or pypi MCP package. There are a ton available, just search "mcp" on npmjs.org for example. The LLM basically just downloads/runs these packages in a sandbox scripting environment, and the package then forwards that to a real API somewhere.

ProGet already supports "MCP" packages. They are just regular npm/pypi packages. And, it turns out... the AI coding tools (Claude et al) already support private package registries. And that's exactly how a lot of our users have been working with ProGet for their AI-assisted teams. They curate these mcp packages just like they would any other.

The future will probably just be packages. I have no idea if MCP will even be a thing in the future. It's just a "quasi API for LLMs". But it's clear that it's heading towards packages already, and I imagine that some ecosystems may add additional metadata inside packages to give the LLM usage instructions. Who knows.

Best,
Alex