notavibe MCP Server

Return the public profiles of two catalog projects side by side, identified by host and two owner/repo slugs. The response presents each project's facts and health bands; it draws no conclusion and names no winner. What each band means is published on the catalog's methodology page (/methodology). The pair is refused when either project is unavailable or has insufficient measured signals. Read-only. Serves catalog schema v1.

List the public curated lists in the notavibe catalog, or return the public members of one list identified by owner handle and list slug. Only public lists and their publishable members are returned; a list that does not exist or is not public returns {"found": false, "subject": "list"}. handle and slug are given together or not at all; one without the other is refused as an invalid argument. Read-only. Serves catalog schema v1.

Records a description of a capability missing from the other tools of this server, for the maintainers of this server. The description is stored by an analytics service. It returns an acknowledgement and adds no tools: every tool of this server is already listed. Reads no catalog data. Serves catalog schema v1.

Return the public profile of one catalog project, identified by host and either an owner/repo slug or a numeric repository id. host and exactly one of slug or id are required; a call missing them, giving both slug and id, or giving a host other than github or gitlab or a slug that is a URL or ends in a slash is refused as an invalid argument and names what is wrong. A well-formed lookup that matches no project is not an error: it returns {"found": false}. This resolves any project the catalog holds, including one below the discovery floor that search does not return. The profile carries the claim state, verification or generation provenance, the vocabulary dimensions (category, ecosystem, kind, runtime, license_family, topics and capabilities, each present only when it has a value), the five health-signal bands, license and package-registry facets, and staleness. Health signals are reported as bands, not raw measures; no person-derived counts are included. What each band means, and its cut-point, is published on the catalog's methodology page (/methodology). Read-only. Serves catalog schema v1.

Search the notavibe catalog of open-source projects. The query matches project name, project description, and the category, ecosystem, kind, runtime, license_family and capabilities vocabulary facets; free-form repository topics are not matched. capabilities names what a project does, such as http-client, logging or database. Its values come from a fixed list kept by this catalog, and a project carries one only when a tag mapped to it is declared on the project's GitHub repository, or on an npm package bound to that repository both ways: the repository's package.json names the npm package, and the package names the repository as its source. Most projects carry no capabilities. A facet match adds a project to the results and does not affect its position in them: results are ordered by how closely the query matches name and description, then by published health signals. Every word of the query must match. A project's description is generated from its facets until its maintainer claims it and writes their own, so a query describing what a project does, such as "http router" or "date parsing", matches only where those words appear in a project name, in a claimed description, or among the words a facet value matches; a project name or a category, kind or ecosystem word is what a generated entry reliably matches. The catalog currently covers one ecosystem: javascript-typescript. category, ecosystem, kind, runtime, license_family, topics and capabilities are also exact filters. Every filter supplied is applied, and a filter combines with the query rather than replacing it: query with ecosystem returns only projects that match the text AND carry that ecosystem. A filter narrows the result set and never changes the order. category, ecosystem, kind, runtime, license_family and capabilities accept only values from this catalog's managed vocabulary; a value outside it is refused and the refusal names the accepted values, so it is never returned as an empty result. A capabilities filter takes one value and matches every project that carries it among its capabilities. topics is an open set, so any topic is accepted and an unrecognised one simply matches nothing. The response echoes the filters that were applied. Search returns projects at or above this catalog's discovery floor — a repository whose measured activity is too low to be ranked is held out of search even though the catalog holds it and has signals for it. A call with a query also returns projects in the settling hold, a waiting period a new or changed entry serves before it can be ranked. A call with filters and no query lists ranked projects only, so it excludes projects in the settling hold. An empty result therefore means that nothing matched among the projects that call can return, which is not the same as the catalog having no such project: a project known by name can still be retrieved by exact identity with get_project. At most 100 results are returned; the response field truncated is true when more matched and the list was cut at 100, and no total is reported. When truncated is true the response also carries next_cursor, an opaque string. A call with the same query and filters and with cursor set to that string returns the next results in the same order; while the catalog is unchanged, no result is repeated or skipped across calls. The last page carries no next_cursor. A cursor is accepted only with the query and filters it was issued for; any other cursor value is refused as an invalid argument. Returns compact result rows: repository host and numeric id, slug, name, description, claim state, category, and the maintenance-rhythm and contribution-breadth health bands. What each band means, and its cut-point, is published on the catalog's methodology page (/methodology). Read-only. Serves catalog schema v1.