Populating overview tab on community servers

[cutecatfann]

What I did

Populate the Overview tab for community registry MCP servers. Previously, docker mcp catalog-next server inspect returned empty readmeContent for community registry servers, leaving the Overview tab blank in Docker Desktop. This PR adds a three-tier fallback chain to resolve README content at inspect time:

1. Baked-in ReadmeURL: If the OCI snapshot already contains a ReadmeURL (like servers imported via docker mcp catalog-next server add), fetch it directly. Failures are now logged as warnings instead of hard errors, since community servers often have derived URLs that point to private or deleted repos.

2. Live registry API lookup: When no baked-in README exists, query the official MCP registry (registry.modelcontextprotocol.io) using the server's Metadata.RegistryURL. Extract the GitHub repository URL from the API response, construct a raw.githubusercontent.com URL via BuildGitHubReadmeURL, and fetch the content. The registry API response is preserved even when the README fetch fails, so its metadata (title, status, websiteUrl) can enrich the synthesized fallback.

3. GitHub API README endpoint (fallback when raw URL 404s): BuildGitHubReadmeURL hardcodes README.md, but raw.githubusercontent.com is case-sensitive. Repos using readme.md or other casing variants return 404. This caused some failures among community servers that have GitHub repos. The GitHub API endpoint auto-discovers the README regardless of filename, recovering those failures.

4. Synthesized markdown overview: When no README content can be fetched (no repo, private repo, non-GitHub host, 404, etc.), construct a structured markdown document from the server's catalog metadata and registry API response. Sections include:

   • Title (from registry API or catalog snapshot)
   • Status (from registry API official metadata)
   • Connection info (remote endpoint with transport type, or Docker image)
   • Tools table (name + description)
   • Configuration properties (extracted from JSON schema)
   • Authentication requirements (OAuth providers, environment variables)
   • Metadata details (category, license, tags)
   • Links (website, MCP registry, endpoint, source repository)
   • Description as last resort if nothing else is available

See example here:

Data: README availability across community registry servers

The mcp/community-registry:latest OCI image contains 1,514 servers (as of March 20 2026). None of them have a ReadmeURL baked into the OCI snapshot (0%), so the entire population depends on this new fallback chain.

Based on sampling the MCP registry API:

Source	% of servers	Estimated count
Full GitHub README (fetched via registry API repo URL)	~42%	~636
Synthesized overview (no repo, private repo, or fetch failure)	~58%	~878

Breakdown of why servers fall through to synthesized:

• ~34% of servers have no repository URL at all on the MCP registry (remote-only servers like Notion, Stripe, etc.)
• ~24% have a GitHub repo URL but the README fetch fails (404, repo deleted, renamed, private, or README in non-standard location)

Additional changes

• BuildGitHubReadmeURL in registry_to_catalog.go: new utility that constructs raw.githubusercontent.com URLs from GitHub repo URLs, handling subfolders and .git suffixes.
• TransformToDocker now derives and sets ReadmeURL from the GitHub repository during import, so future OCI snapshots carry the URL for tier-1 lookup.
• InspectServer signature updated to accept a registryapi.Client for live API lookups.
• README fetch errors are now warnings (stderr) instead of fatal errors, preventing a single broken URL from blocking the entire inspect response.