Scope of "search" functionality within official metaregistry

[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

"Search" is functionality that should likely exist in some form for consumers of the metaregistry.

However, I want to be careful of the scope of what the metaregistry should try to solve.

A simple use case for search is: "I want to see whether my teammate already published our server to the registry"

A more complex use case for search is: "I am an end-user, and I want a list of options for what server I should use for my use case"

I believe we should focus on the former use case, and deliberately avoid solving the latter use case for two major reasons:

1. It is an infinite problem. Google Search as a business has invested billions of dollars into solving the problem of "ranking websites", and they still get mountains of feedback every day for why there are problems with their approach. If the MCP ecosystem evolves as we expect it to, this problem of surfacing and ranking MCP servers in response to some query will be of similar scale and complexity to serve well.
2. As a vendor-neutral OSS project, we shouldn't take an opinion on what results are relevant to a query vs. what is not. So anything beyond some fairly objective metric, like an exact string match, is prone to snowballing into controversy like "why isn't your vector search algorithm tuned to show XYZ result over ABC result".

As such, I would urge us to focus on very basic search functionality: perhaps nothing more than "exact string match on MCP server name". Maybe including a provision for fuzzy match when the edit distance is small enough.

Even "string match on description" feels like a potential rabbit hole, because it will create an incentive to keyword-stuff descriptions. The intent of keeping search barebones is deliberately to discourage direct usage of the metaregistry's Search API and encourage an ecosystem of better downstream solutions to emerge on top of the data collated by the metaregistry.

Curious to folks' opinions: do you agree? If you don't, how would you address the concerns above?

[ariadng]

Agree with the basic search functionality. A simple description search can be implemented though, as long as there is a limit on description character length to prevent the incentive to keyword-stuff descriptions.

More advanced search should be implemented by 3rd parties if they decide to adopt this metaregistry. Or, we can revisit this later for future version after the project is mature enough.

[kentcdodds]

I agree with your assessment, but I still want somebody to build the Google of MCPs. But it does make sense that this would be outside the scope of the registry. Disappointing, but probably the right call. Whoever does this needs to understand that it could consume the next few decades of their life and attention 😅 It can't be the work of individuals doing this in their free time.

[kirk-marple]

Very fair point. We've built this already as a tech demo, and given there's <10k active MCP servers now, it was a weekend project to build the ingestion pipeline from the GitHub READMEs.

We're using our Graphlit platform as the backend RAG for it.

https://www.mcpoogle.com/

It works pretty well, and also supports structured data extraction from each MCP, which could help be a starting point for the MCP registry if anyone wants it.