Repository navigation
Pingback from subregistries with extension data #292
Description
Activity
But we are effectively privileging some group of registries, so we probably want to come up with some fair and community-accepted set of criteria for entering this group.
This is probably my biggest concern with this -- keeping this level of the ecosystem fair/objective, free market without giving incumbents a systematic advantage at the protocol layer here is something I feel motivated to avoid structurally.
Versus the alternative seems pretty workable, in that the downstream registries all have matching FK's in the form of server names, and so if you trust Anthropic's perspective, you ETL and zip up their data; then do the same with PulseMCP, etc. If everyone is following the Registry API, you can probably even do this with a single SDK, or even a one-liner to just add the relevant subregistry URLs and facilitate a zipped-up sync without directly pointing to defaults. Like:
registry_urls = [ "registry.modelcontextprotocol.io", "registry.pulsemcp.com", "mcp-registry.anthropic.com" ] all_mcp_servers = registry_sdk.zip_all_from(registry_urls) return all_mcp_servers
Yeah! I like the idea of building nice utilities or an SDK for registry that makes doing the above easy.
I think I'd probably like to wait and see how the registry ecosystem develops, then I think whether this is valuable/reasonable will become a lot clearer. And we'll discover more about how the community would feel re: privileging some group of registries (e.g. If it turns out there are basically only 4 registries run by the big companies anyways, then there probably won't be any arguments. If everyone and their dog runs a registry with extra value-add annotations they're asking to add back to the official registry, then this is a lot more painful). We'd also discover more about what value-add annotations people are even adding at all, and what the community demands from registry, to see if this is even worth doing.
Reacted by Tadas Antanavicius, Radoslav Dimitrov and Dominik Guhr@domdomegg for oci packages, there's some prior art here with the OCI referrers api. We have some tools that we could potentially add to the publisher api to verify signed attestations. I'll attach some examples later in the week.
Use case
Anthropic will probably run a subregistry, where we do light security scanning and maybe mark some things as 'Verified' publishers etc. I also expect others will too (e.g. GitHub, Microsoft, ...).
I reckon it would be useful for the official registry UI to show some of these verifications from reputable subregistries i.e. checkmarks like '☑️ Security scanned by Anthropic and GitHub' or '☑️ Publisher name verified by Microsoft and Google'.
I also think other subregistries might benefit from these annotations. E.g. if I'm running a corporate MCP registry for my employees, it would be quite useful to have the data of security scans from the main registries available with one seed sync from the official registry (rather than having to set up syncs and deduplication from a bunch of registries myself). So it would be useful on the API.
Challenges
x-com.anthropicextension space in the official registry