Repository navigation
Add 'Server List Filtering' into OpenAPI spec #389
Description
Activity
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)
Reacted by Tadas AntanaviciusYeah 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.
The
versionquery parameter only supportlatest, I don't see much use cases where you would search by version other than latest, so maybelatestshould be boolean optional query parameter instead?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
nameandversion, soversionis very critical (it's conceptually part of a composite primary key), and I don't think there is an opportunity to simplify there.- added a commit that references this issue
on Dec 5, 2025 Closing this out. All three filters requested here (
search,updated_since,version) are documented in the OpenAPI spec atdocs/reference/api/openapi.yaml(and rendered atregistry.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.
In #374, it supports
updated_since,search, andversionquery parameters.Please also help make them include them in the official OpenAPI spec, so that other subregistries could align and follow them.
Especially the
searchandversionquery parameters are very helpful to client maintainers which consume the regsitry APIs:searchis helpful for query and pagination.version=latestis helpful for client to avoid show dupilcated MCP server with multiple versions.