Add 'Server List Filtering' into OpenAPI spec

[formulahendry]

In #374, it supports updated_since, search, and version query parameters.
Please also help make them include them in the official OpenAPI spec, so that other subregistries could align and follow them.

Especially the search and version query parameters are very helpful to client maintainers which consume the regsitry APIs:

• search is helpful for query and pagination.
• version=latest is helpful for client to avoid show dupilcated MCP server with multiple versions.

[domdomegg]

Yeah, I think it's likely that we add something like this to the official spec in time.

Some discussion here about whether we should do this, where I suggested in the first instance that we shouldn't so that we can experiment a bit with the filters: #291 (comment)

[tadasant]

Yeah I'd like to build confidence that these are the right shapes before we bake them into the standard.

To give an extreme counter-example: WoT's Discovery spec uses JSONPath/XPath/SPARQL for exposing search capabilities. I'd like to see someone think through the argument for why we wouldn't eventually want something sophisticated like that, especially when pushing this federated, opinionated subregistry model.

[axel7083]

The version query parameter only support latest, I don't see much use cases where you would search by version other than latest, so maybe latest should be boolean optional query parameter instead?

[tadasant]

The version query parameter only support latest, I don't see much use cases where you would search by version other than latest, so maybe latest should be boolean optional query parameter instead?

The query parameter should support any string there (let us know if you see otherwise).

The only way to uniquely identify a server.json file is a combination of name and version, so version is very critical (it's conceptually part of a composite primary key), and I don't think there is an opportunity to simplify there.

[rdimitrov]

Closing this out. All three filters requested here (search, updated_since, version) are documented in the OpenAPI spec at docs/reference/api/openapi.yaml (and rendered at registry.modelcontextprotocol.io/docs). The broader discussion in-thread about more sophisticated filter shapes is a separate design question; worth a fresh, narrower issue if that direction resurfaces.