MCP Server List

Track Glama ingestion

Official-registry ingestion followed by verification of source identity, completed evaluation, and actual directory discovery.

Observe registry ingestion, evaluation and exact discovery evidence. This action is separate from the qualifying submission minimum.

Registry ingestion and verificationSources checked

What to prepare

  • A valid official registry identity with a verified existing record or an eligible official-registry publication in the same launch.
  • A reproducible source package or reachable remote endpoint that can complete Glama’s evaluation.
  • The service operator’s authenticated Glama discovery integration and an available verification worker.

A profile, an evaluation, and a discoverable listing

These are distinct states. A source profile can remain on Glama when a reproducible build fails, while search distribution is withheld. Static repository inspection identifies preparation issues at a pinned commit; only Glama can establish its build, runtime introspection and evaluation results. A successful page fetch does not establish discoverability.

The worker checks the exact repository or endpoint identity, an evaluated tool-definition score, and the matching provider record in discovery results. A remote connector also needs a completed healthy test and must not be deprecated. Unknown or incomplete evaluation remains pending.

Publish through the documented ingestion route

Glama describes its catalog as a superset of the official MCP Registry. MCP Server List can publish an eligible registry record and follow the resulting Glama ingestion, or use a verified existing registry record as the source. Registry publication is evidence of the upstream action; it does not establish that Glama has finished its own checks.

A launch can therefore show awaiting_ingestion after the registry action succeeds. If evaluation or discovery cannot be confirmed within the supported checking window, the record remains unresolved rather than becoming a fabricated listing.

Ownership management remains separate

Glama’s direct repository submission and claim flows use the maintainer’s authenticated identity. Personal repositories can use GitHub authentication; organization repositories need confirmed maintainers in root glama.json for ownership claims. This file is ownership metadata, not a submission receipt or runtime evaluation. Remote connector claims use their own domain or eligible GitHub verification.

A root Dockerfile can make the intended build reproducible, but its presence does not prove that Glama built or introspected the server. Glama may infer a Dockerfile or use its Admin build configuration; absence alone is not a documented rejection. Confirm the actual build and captured tools, and keep sandbox credentials private. Never publish a session, service API key or production connector credential in an ownership file.

{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": ["your-github-username"]
}

Submission workflow

  1. Check for an existing exact repository or connector record during the free preflight.
  2. Approve the official-registry publication and dependent Glama verification scope where a new registry record is needed.
  3. After verified payment, let the worker publish or confirm the registry record and wait for Glama ingestion.
  4. Confirm evaluated discovery evidence; a retained profile or guessed badge URL is not completion.

Blockers to resolve before review

Use these as preparation checks. The destination makes its own acceptance decision.

  • Repository metadata cannot be fetched or the repository is not a supported source.
  • The server does not start or cannot answer introspection requests in the indexing environment.
  • Ownership metadata has invalid JSON or names the wrong GitHub maintainer.

Primary sources

Checked 2026-10-29. Follow the destination’s current instructions if its requirements change.

← Compare all destinations