Add a verified field to MCP Registry assets to support trusted publisher workflows

[sebytremblay]

Is your feature request related to a problem? Please describe.
I’m building an MCP sub-registry that ingests servers from the Central MCP Registry and republishes them in a more opinionated / curated way. For security and governance reasons, I currently need a human-maintained allowlist of “trusted” MCP servers before I can automatically surface them to downstream users.

Right now, the Central MCP Registry doesn’t expose any explicit notion of “verified” publishers or servers. As a result, any automated ingestion pipeline has to treat all registry entries as equally trusted, or bolt on its own external allowlist logic. This limits how many MCP servers I can safely expose and requires ongoing manual curation to meet internal requirements.

Describe the solution you'd like
Introduce a first-class verified field (or equivalent) in the MCP Registry schema that indicates whether a server is published by a verified/trusted publisher.

For example, at the asset level:

• verified: true | false – whether this server is from a verified publisher.
• (Optionally) verifiedBy: "registry" / "community" / "publisher" – who performed the verification, if you want to support multiple trust sources.
• (Optionally) publisherId / publisherSlug – a stable identifier for the publisher so downstream systems can group and filter by publisher.

The important part is that the Central MCP Registry defines and enforces a verification process (e.g., tied to a verified GitHub org, domain, or registry-managed onboarding) and exposes the result via a machine-readable field. This would let sub-registries and tools:

• Automatically ingest all servers from verified publishers without maintaining a separate allowlist.
• Safely apply different policies (e.g., “auto-include verified; require review for unverified”) in CI/CD or governance workflows.
• Treat the Central MCP Registry as a more reliable source of truth for “high-trust” MCP servers.

Describe alternatives you've considered

• Manual allowlist in the sub-registry:
  Maintain a YAML/JSON allowlist of server identifiers or publisher names. This works but does not scale: every new server or publisher requires a human to update config and re-deploy.

• Heuristics based on GitHub org / repo metadata:
  Infer trust from things like a verified GitHub org, star count, or popularity. This is brittle and not standardized; different consumers will implement different heuristics, fragmenting the ecosystem.

• Tags or custom fields in the registry that are not formally governed:
  Use a tag like trusted or official in descriptions or freeform metadata. Without a shared definition and governance process, these can’t safely be used for automated decisions.

Additional context
My specific use case is an MCP sub-registry that:

• Periodically syncs from the Central MCP Registry.
• Publishes MCP servers into another ecosystem based on policy (e.g., only verified publishers can be auto-enabled; others require review).
• Needs to satisfy internal security/governance requirements that prohibit auto-exposing arbitrary third-party servers.

A standardized verified field and associated process in the Central MCP Registry would enable safer programmatic consumption, reduce duplicated curation work across downstream registries, and encourage more organizations (especially enterprise users) to rely on the official registry as their primary discovery mechanism.