Research: publish MCP server metadata for discovery and catalog ingestion

[ajdelaguila]

Source signal

The outreach pass surfaced OpenHands/extensions#351, which is adding generated MCP server.json artifacts from integration catalog entries:

• Generate MCP server.json from integration catalog entries OpenHands/extensions#351
• Data Olympus field note: Generate MCP server.json from integration catalog entries OpenHands/extensions#351 (comment)

The same need appears in the outreach index for the official MCP Registry, punkpeye/awesome-mcp-servers, Smithery, PulseMCP, MCP Directory, and Copilot-facing resource submissions.

Current Data Olympus behavior

Data Olympus exposes a Streamable HTTP MCP server and has setup documentation, but it does not yet publish a stable machine-readable server metadata artifact for registries or downstream catalogs.

That leaves discovery targets with incomplete information about:

• transport and default local endpoint;
• self-hosted versus SaaS assumptions;
• required local git-backed KB bundle path and index path;
• optional remote/push configuration;
• read-only lookup versus proposal/write capability;
• license, categories, package/install hints, and security expectations.

Research questions

• Which metadata format should be canonical for Data Olympus: official MCP server.json, repository-local catalog metadata, or both generated from one source?
• How should local-first configuration be represented without implying a hosted SaaS endpoint?
• Should write/proposal capability be first-class metadata so catalogs and agent hosts can distinguish retrieval-only use from governed KB mutation?
• What minimum metadata is required for official MCP Registry publication and high-visibility MCP directories?
• Can the same metadata support Copilot/Codex/Claude Code-facing packaging without duplicating install instructions?

Candidate shape

Evaluate a single source of truth that can generate or validate:

• server.json or equivalent official MCP registry artifact;
• directory/listing snippets for MCP directories;
• README install metadata;
• future Codex/Copilot/Claude Code packaging hints.

Candidate Data Olympus-specific fields may need to describe:

• kb_bundle_path or workspace-local knowledge bundle path;
• index_path / generated index location;
• optional git remote and push behavior;
• allowed modes: lookup, consult gate, propose memory, resolve pending;
• deployment mode: local, team-hosted, or behind auth/proxy.

Evaluation criteria

• A user can discover Data Olympus through MCP catalogs without reading a long issue comment.
• Metadata does not misrepresent Data Olympus as a hosted SaaS integration.
• Generated artifacts remain consistent with setup documentation.
• Downstream catalogs can preserve enough safety context for write/proposal tools.
• The artifact can be used as a fixture for OpenHands-style catalog generation.

Non-goals

• Do not submit broad directory listings before the metadata is accurate.
• Do not create a hosted Data Olympus service as part of this issue.
• Do not make catalog comments a substitute for installable metadata.

[ajdelaguila]

Outreach learning: Glama inspection is the concrete acceptance target

The punkpeye/awesome-mcp-servers PR now requires a Glama score badge, and Data Olympus is already indexed at:

• https://glama.ai/mcp/servers/knaisoma/data-olympus
• schema page: https://glama.ai/mcp/servers/knaisoma/data-olympus/schema

Current state observed on 2026-07-09:

• Glama lists the repo under Knowledge & Memory / Documentation Access.
• The overview reflects the current v0.4.1 README.
• The page says Install Server: This server cannot be installed.
• The schema page says the server has not been inspected and shows no tools, prompts, or resources.
• The awesome-mcp PR needs a working Glama badge: Add Data Olympus to Knowledge & Memory 🤖🤖🤖 punkpeye/awesome-mcp-servers#9732

This sharpens the acceptance criteria for this issue: the metadata/distribution work should make Data Olympus inspectable by Glama and other registries, not merely present as a README-derived listing.

Concrete acceptance candidates:

• Provide the registry metadata and runtime entrypoint Glama needs to start the server for introspection.
• Ensure Glama can see the actual MCP tool schema instead of “No tools”.
• Document whether the inspection target should use an example bundle, a generated temp bundle, or a read-only demo bundle.
• Keep local-first configuration honest: do not imply a hosted SaaS endpoint, but do provide an installable/inspectable local server shape.
• Once fixed, update the punkpeye PR badge if the Glama path or score badge URL changes.