GitHub Copilot MCP Registry

Canonical version: GitHub Copilot MCP Registry.

GitHub Copilot MCP Registry is the ability, in public preview, to point a GitHub organization or enterprise at a private MCP registry so that GitHub Copilot clients only discover, and optionally only allow, the MCP servers your company approves. Admins configure it under AI Controls → MCP in the org/enterprise Copilot policies: set the MCP Registry URL and pick the enforcement level, "Allow all MCP servers" (discovery only) or "Registry only" (hard allowlist).

It serves three jobs at once:

  1. Document: the registry is the single inventory of approved MCP servers, with their source, transport, endpoints, packages, and runtime parameters
  2. Enforce: with "Registry only", any server not in the registry is blocked; in Visual Studio Code (VSCode) it shows disabled with a warning, and the MCP access control setting is greyed out so users can't loosen it
  3. Discover: developers browse and install approved servers directly from their client. In Visual Studio Code (VSCode), type @MCP in the extensions view and only registry servers appear. In GitHub Copilot CLI, /mcp search (experimental) searches the public GitHub MCP Registry by default, but once an org/enterprise registry URL is configured it connects to that registry instead; /mcp add then pre-populates the configuration form (command, args, env, headers) from the registry entry, so wiring up an approved server is fill-in-the-secrets-and-save

Registry requirements

Any registry implementing the Model Context Protocol Registry v0.1 spec works. Required endpoints:

  • GET /v0.1/servers
  • GET /v0.1/servers/{serverName}/versions/latest
  • GET /v0.1/servers/{serverName}/versions/{version}

All must return permissive CORS headers (Access-Control-Allow-Origin: *). You can self-host the open-source reference registry, roll your own, or use Azure API Center as a managed registry (its endpoint format: https://<name>.data.<region>.azure-apicenter.ms/workspaces/default; GitHub appends /v0.1/servers itself, and the workspaces/default segment is mandatory).

Client support

The v0.1 registry is consumed by VS Code (Stable and Insiders), Visual Studio, JetBrains IDEs, Eclipse, Xcode, and GitHub Copilot CLI. In the CLI, servers land in ~/.copilot/mcp-config.json (project-level .mcp.json / .github/mcp.json override it), managed via /mcp show|add|edit|disable|delete or the copilot mcp subcommands; when a registry URL plus allowlist policy is set at org/enterprise level, only allowlisted servers execute regardless of how they were configured.

Registry vs managed settings

Two overlapping control planes exist for MCP governance, and GitHub itself calls GitHub Copilot Managed Settings the "more secure, production-ready" option:

  • MCP Registry (this note): preview; optimized for discovery plus allowlisting; needs a spec-compliant registry endpoint (currently anonymous-read)
  • allowedMcpServers / deniedMcpServers in managed-settings.json: GA; pure allow/deny matching by server name, URL pattern, or exact command; no discovery experience

In practice they compose: the registry gives developers a curated storefront, managed settings give admins the hard enforcement floor.

Caveats

  • The registry endpoint must currently allow anonymous read access (authenticated private endpoints aren't supported yet), so don't put secrets in server metadata
  • An MCP server with an empty description field doesn't show up in VS Code's gallery
  • Policy changes need a client restart to propagate

References


About Sébastien

Ready to get to the next level?

Found this valuable? Share it with someone who needs it.

Join 6,000+ readers. Get practical systems for knowledge & AI. Free.

Subscribe ✨

Free: Knowledge System Checklist

A clear roadmap to building your own knowledge system. Subscribe and get it straight to your inbox.

6,000+ readers. No spam. Unsubscribe anytime.

Subscribe