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

## 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`:

```json
"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:

```bash
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.

Trace the production path for the `mcp-registry-approved` source set, comparing how the registry record supplies `description` with the existing `capabilities` and `tags` handling. Review `internal/ingestion/mcp-server-2025-12-11.schema.json` and the affected artifact records, then verify that missing descriptions are rejected or flagged and the 29 listed entries are backfilled.

Written by the indexing model from the issue text.