You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
mcp-registry-approved artifact production drops description, losing it for 29 servers #19
Catalog entries produced for the mcp-registry-approved source set are written without a description, even though the upstream MCP registry serves one for every affected server. This is a data-loss defect in artifact production: the field is present at the source and absent in the artifact.
29 entries are affected. All 29 are application/mcp-server+json and all 29 are sourceSet: mcp-registry-approved.
Why this matters downstream
In github/agentfinder, an entry is embedded for semantic search as DisplayName + "\n" + Description (entryText, internal/search/catalog.go). With no description, these entries embed as nothing but their name — Neon's embedded text is literally "Neon". They are effectively unfindable by meaning-based search. Neon ranked 1775 for manage a postgres database; Logfire ranked 215 for monitor app performance and traces.
Evidence that the text exists upstream
1. The schema requires it. The MCP server schema pinned at internal/ingestion/mcp-server-2025-12-11.schema.json in github/agentfinder defines description as required on ServerDetail with minLength: 1:
3. It is specifically the description field. 24 of the 29 carry populated capabilities and tags derived from that same registry record. Neon's capabilities read run sql queries and perform database migrations. So the record was read during production and other fields were taken from it — description alone was not carried through.
Carry description through when producing mcp-registry-approved artifacts, from the same registry record capabilities and tags are already derived from.
Reject or flag an MCP server artifact written without a description, since the schema requires one — that would have caught this at production time.
Backfill the 29 entries above.
Related
github/agentfinder#238 adds a compensating fix in the consumer: the catalog sync backfills a blank MCP server description from the registry record the entry URL points at. That restores search quality for Agent Finder, but it is not the root fix — it is a consumer working around missing data, and it costs a network fetch per affected entry on every sync until this is resolved here. Every other consumer of this catalog still sees the entries with no description.
Tracking issue for the downstream symptom: github/copilot-ecosystem#1315.
Activity