New features
Keep any catalog search as a collection
Any question you can ask the catalog, you can now keep. A dynamic collection is written in the same query language as the search box, so it can finally express what the old filter form could not: an OR across kinds, a NOT on a tag, a date range, or a comparison on one of your own fields.
Picking a collection kind up front is gone. What those kinds did is now something
you type. Use interface:mcp for the entities publishing an MCP server,
hasDocs:true for the ones carrying documentation, and both together with
everything else in a single expression. Those four new fields, interface,
interfaceVisibility, protocol, and hasDocs, work in the catalog search box
too.
The collection editor is the catalog's own search box, with the same field suggestions and syntax help, above a live preview of exactly which entities the collection would contain as you type. A collection's page shows its query and links straight back into the catalog with it loaded, so widening a collection and saving the result as a new one takes seconds.
Your existing dynamic collections keep working. Each one's filter is rewritten as the query that selects the same entities.
Ask the catalog a real question
Search now understands more than words. Type
lifecycle:production AND (language:go OR language:rust) AND NOT tag:deprecated
into the search box and you get exactly that. You can filter on any built-in or
custom field, combine those filters with AND, OR, NOT and parentheses, and use
comparisons like replicas:>=3, date ranges, wildcards, and tests for whether a
field is set at all. Plain words still work exactly as before, and you can mix
the two.
The search box suggests field names as you type, carries a syntax reference, and tells you precisely where a query went wrong instead of quietly returning nothing. Filter chips and expressions work together, and one click rewrites your active filters as a query you can refine.
The same expression works everywhere the catalog does, including the REST API and the MCP tools your AI agents use, so an agent can ask in one call what used to take several.
Improvements
See who's asking before you approve access
When an AI agent or third-party tool asks to connect to your Componecat organization, the approval screen now shows the client's registered name instead of an opaque identifier. You can tell what you are authorizing before you grant it. "Cookie settings" has also moved from the sidebar's app-info popover into your account menu, alongside your other personal settings.
One catalog, however you look for things
Browse and Search were separate screens that did the same job, and only one of them had the good search. They are now a single Catalog page. Open it and you see your whole catalog; start typing and it narrows. Facet counts, the query language, documentation matches, and relevance ranking are there the whole time, not just after you switch screens.
A toggle switches between the hierarchy tree and a ranked list, and your choice sticks and travels in any link you share. Filtering no longer flattens the tree — matches stay where they belong, with any parent that did not match shown dimmed above them, so you can still see where something lives.
Results are properly paged now, so a search that finds 312 things lets you reach
all 312 rather than showing 25 under a count of 312. You can also sort the list by
relevance, name, or most recently updated. Old /search links still work.