`mcp-registry-approved` artifact production drops `description`, losing it for 29 servers

[aphansal123]

Summary

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:

"description": { "maxLength": 100, "minLength": 1, "type": "string" },
"required": ["name", "description", "version"]

2. The registry serves it today — 29 of 29. I fetched every affected entry's own url and every one returned a non-empty description:

resolved with description: 29/29

Worked examples, showing the exact text that is being lost:

Entry	Registry URL	description served upstream
Neon	.../servers/neondatabase%2Fmcp-server-neon/versions/latest	MCP server for interacting with Neon Management API and databases
Logfire	.../servers/pydantic%2Flogfire-mcp/versions/latest	Provides access to OpenTelemetry traces and metrics through Logfire.
Playwright	.../servers/microsoft%2Fplaywright-mcp/versions/latest	Automate web browsers using accessibility trees for testing and data extraction.

Reproduce with:

curl -s -H 'Accept: application/json' \
  'https://api.mcp.github.com/v0.1/servers/pydantic%2Flogfire-mcp/versions/latest' \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["server"]["description"])'

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.

Affected identifiers (29)

• urn:ai:registry.modelcontextprotocol.io:amplitude:mcp-server-guide — Amplitude
• urn:ai:registry.modelcontextprotocol.io:azure-ai-foundry:mcp-foundry — Azure AI Foundry
• urn:ai:registry.modelcontextprotocol.io:microsoft:azure-devops-mcp — Azure DevOps
• urn:ai:registry.modelcontextprotocol.io:azure:aks-mcp — Azure Kubernetes Service
• urn:ai:registry.modelcontextprotocol.io:box:mcp-server-box-remote — Box
• urn:ai:registry.modelcontextprotocol.io:chroma-core:chroma-mcp — Chroma
• urn:ai:registry.modelcontextprotocol.io:microsoft:clarity-mcp-server — Clarity
• urn:ai:registry.modelcontextprotocol.io:codacy:codacy-mcp-server — Codacy
• urn:ai:registry.modelcontextprotocol.io:cognitionai:deepwiki — Deepwiki
• urn:ai:registry.modelcontextprotocol.io:microsoft:devbox-mcp-server — Devbox
• urn:ai:registry.modelcontextprotocol.io:elastic:mcp-server-elasticsearch — Elasticsearch
• urn:ai:registry.modelcontextprotocol.io:microsoft:fabric-rti-mcp — Fabric RTI
• urn:ai:registry.modelcontextprotocol.io:firecrawl:firecrawl-mcp-server — Firecrawl
• urn:ai:registry.modelcontextprotocol.io:huggingface:hf-mcp-server — Hugging Face
• urn:ai:registry.modelcontextprotocol.io:sunriseapps:imagesorcery-mcp — Imagesorcery
• urn:ai:registry.modelcontextprotocol.io:intercom:intercom-mcp-server — Intercom
• urn:ai:registry.modelcontextprotocol.io:launchdarkly:mcp-server — LaunchDarkly
• urn:ai:registry.modelcontextprotocol.io:pydantic:logfire-mcp — Logfire
• urn:ai:registry.modelcontextprotocol.io:microsoft:markitdown — Markitdown
• urn:ai:registry.modelcontextprotocol.io:microsoftdocs:mcp — Microsoft Docs
• urn:ai:registry.modelcontextprotocol.io:neondatabase:mcp-server-neon — Neon
• urn:ai:registry.modelcontextprotocol.io:makenotion:notion-mcp-server — Notion
• urn:ai:registry.modelcontextprotocol.io:antfu:nuxt-mcp — Nuxt
• urn:ai:registry.modelcontextprotocol.io:octopusdeploy:mcp-server — Octopus Deploy
• urn:ai:registry.modelcontextprotocol.io:microsoft:playwright-mcp — Playwright
• urn:ai:registry.modelcontextprotocol.io:oraios:serena — Serena
• urn:ai:registry.modelcontextprotocol.io:doist:todoist-ai — Todoist AI
• urn:ai:registry.modelcontextprotocol.io:coplaydev:unity-mcp — Unity
• urn:ai:registry.modelcontextprotocol.io:zapier:zapier-mcp — Zapier

Asks

1. Carry description through when producing mcp-registry-approved artifacts, from the same registry record capabilities and tags are already derived from.
2. Reject or flag an MCP server artifact written without a description, since the schema requires one — that would have caught this at production time.
3. 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.