"Sorting signals" functionality within the metaregistry and API

[tadasant]

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

This is likely related to the scope of "search": #13

@toby had raised the idea of "sorting signals":

I'd love a service agnostic way to add social signals. if we think about federated registries (the modelcontextprotocol registry, internal enterprise registry...) it would be nice for hosts to pick and choose what they sorted by. For instance, VS Code probably would use stars, but maybe Cursor would use downloads or something... this isn't a very baked thought 😂 I just think it would be nice to have the option for "signals": ["github/stars=200", "mcp/downloads=200000"] or "signals": ["gitlab/stars=200", "mcp/downloads=200000"] type thing.

I think including a possibility for sorting signals is a good idea. With a few caveats:

• Similar to the discussion on Search, I want to avoid us trying to centrally solve a multi-billion dollar problem: "search ranking" is a rabbit hole that Google Search has been iterating on for decades
• I think MCP client apps of different kinds - IDE's vs. chat apps vs. agent frameworks vs. etc - will all have extremely varying needs for "what the right result is." The right MCP server for a developer to accomplish a task is likely very different than a nontechnical salesperson making a similar search.

So while I think including sorting signals is a good feature to include in the API, I do think it should be up to consumers of the metaregistry to integrate their own opinionated sorting signals, fit for the long tail audience (the MCP client app's users) they are serving. This keeps the scope of the problem much more manageable and distributed.

I think it would be reasonable for us to include a notion of "MCP server downloads" that comes directly from the metaregistry itself, similar to PyPi downloads (and all the caveats that come with such a metric). Because nobody else has access to that data, so we may as well capture it and use it as a somewhat helpful default search result order.

I am less fond of potentially including other metrics like GitHub stars as a default signal in the metaregistry, because:

• They are not vendor-neutral
• They do not map cleanly to the notion of MCP servers. For example, the modelcontextprotocol/redis server lives in a very legit repository with 40k+ stars, but it has only been live for ~1 month and doesn't have any significant kind of real adoption.

Curious what folks think about just including the "MCP server downloads" metric vs. considering including other sorting signals; and whether sorting signals as a concept makes sense.

[olaservo]

I think it would be reasonable for us to include a notion of "MCP server downloads" that comes directly from the metaregistry itself, similar to PyPi downloads (and all the caveats that come with such a metric). Because nobody else has access to that data, so we may as well capture it

Capturing this and giving it visibility seems like a good idea independent of how its used. 👍 Rather than categorizing these as 'sorting signals' I would also heavily plus one the idea that

IDE's vs. chat apps vs. agent frameworks vs. etc - will all have extremely varying needs for "what the right result is."

so it seems that the role of the metaregistry here is more to give consumers ingredients to figure that out, that aren't already accessible elsewhere.

[ariadng]

Including PyPi or NPM downloads is a good idea. Although not perfect, this give the users/clients a rough insight on real usage of the listed servers (once again, not perfect).

[tadasant]

There will be a reference to pypi or npm package names, so consumers of the API could fetch the download counts from those registries if they so please -- we wouldn't need to maintain a mirror of that data in our metaregistry here.