Support authenticated (OAuth/token) reads of the MCP registry so enterprises don't have to expose it anonymously

[eggboy]

Describe the feature or problem you'd like to solve

When a custom MCP registry is configured for an organization/enterprise (for example Azure API Center, a documented Copilot-supported registry type), Copilot CLI reads that registry without any authentication. The lookup is an unauthenticated request:

GET {registryUrl}/v0.1/servers/{name}/versions/latest
Accept: application/json

There is no Authorization header and no way to make the CLI present credentials when reading the registry. This forces the registry to permit fully anonymous reads.

For Azure API Center that means enabling "allow anonymous access", which publicly exposes the organization's entire curated MCP inventory — server names, package coordinates, remote URLs, and metadata — to anyone on the internet.

This is a governance contradiction: the MCP allowlist exists to tighten security, but adopting it currently requires making the source of truth (the registry) world-readable.

There is also a fail-closed interaction: an auth-gated registry returns 401/403, which is neither 200 (verified) nor 404 (not found), so all non-default MCP servers get blocked. A private registry is effectively unusable today.

Proposed solution

Allow Copilot CLI to authenticate the registry read so the registry can stay private. Any one of these would solve it:

• OAuth 2.0 (client-credentials or device-code) against the registry's auth server — preferred for API Center behind Microsoft Entra ID.
• A configurable bearer token / API key header for the registry endpoint.
• Reuse of the identity the CLI already holds. The CLI already sends Authorization: Bearer <token> to GitHub's own policy endpoint and to …/enterprise/v0.1/allowlists/evaluate; the same authenticated pattern simply isn't applied to the configured registry read.

Benefit: enterprises can adopt MCP allowlisting/governance without making their internal MCP catalog public, and private registries (API Center with Entra auth, internal gateways) become usable instead of failing closed.

Example prompts or workflows

• An enterprise admin registers a private Azure API Center (Entra-gated) as the org MCP registry. copilot authenticates to it, fetches the curated server list, and only allowlisted servers run — without the catalog being publicly readable.
• A team fronts its registry with an internal API gateway that requires a bearer token; the CLI is configured with an OAuth client and reads the registry over an authenticated channel.
• A regulated org needs an audit trail of who reads the MCP catalog. Anonymous access makes this impossible today; authenticated reads tie each fetch to an identity.

Additional context

• VS Code has the equivalent request: Feature Request: OAuth Authentication Support for MCP Registry Queries microsoft/vscode#282456 ("authenticated/OAuth registry reads"). The underlying registry-spec support for auth has been addressed upstream; the client side is the remaining gap.

---

Spec confirmation: OAuth2 reads are explicitly supported

The MCP registry authorization spec defines the registry as an OAuth 2.1 Resource Server and defines a dedicated read scope:

"The registry acts as an OAuth 2.1 Resource Server, identical to how MCP servers work."
Scopes: mcp-registry:read (list/read server metadata), mcp-registry:write (publish/update/delete).

• Registry authorization spec: https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/registry-authorization.md
• MCP Authorization Specification (referenced by the above): https://modelcontextprotocol.io/specification/draft/basic/authorization

Authenticated reads are optional per spec ("No authentication required by default. Subregistries may optionally require authentication") — but they are a first-class, spec-blessed capability. So this request is purely a client-side gap: a custom registry (e.g. API Center behind Microsoft Entra ID) is entitled by the spec to require OAuth on reads via mcp-registry:read, and Copilot CLI currently cannot satisfy it because it sends no Authorization header on the registry lookup.