Configure MCP server access for your organization or enterprise

Overview

An MCP registry is a directory of Model Context Protocol (MCP) servers that acts like a catalog for IDEs and Copilot (as well as other host applications). Each registry entry points to a server's manifest, which describes the tools, resources, and prompts that server exposes.

As an enterprise or organization owner, you can configure an MCP registry URL, allowing you to:

• Provide a curated catalog of MCP servers your developers can discover and use
• Restrict access to unapproved servers for increased security and compliance
• Give clarity to developers when a server is blocked by policy

If you haven't created an MCP registry yet, see Setting up an MCP registry later in this article.

About MCP policy settings

The following settings let you control how MCP servers are discovered and accessed in your organization or enterprise.

MCP servers in Copilot

First, you must set the overall MCP servers in Copilot policy:

• Enabled for all: MCP servers are allowed (default behavior depends on registry configuration)
• Disabled for all: No MCP servers can be used by any users with Copilot seats from this enterprise or organization
• Let organizations decide (Enterprise only): Child organizations can set their own MCP policies

MCP Registry URL

The MCP Registry URL is an optional field where you specify the URL of your discoverable or restricted internal MCP registry. When you configure a registry URL:

• The servers listed in the registry are displayed in supported IDEs
• The "Restrict MCP access to registry servers" setting becomes configurable

Restrict MCP access to registry servers

Under the Restrict MCP access to registry servers setting, you choose how strictly to enforce registry-based access:

• Allow all (default): Developers can run any local and remote MCP servers. Registry servers are still shown in the IDE catalog as a curated list for easier discoverability.
• Registry only: Developers can only run MCP servers that are explicitly listed in the uploaded MCP registry. In IDE UIs, blocked servers appear greyed out with a warning message. In the mcp.json configuration file, they may also show "run": "blocked".

Current enforcement limitations

The "Registry only" setting currently has the following limitations:

• Enforcement is based only on server name/ID matching, which can be bypassed by editing configuration files
• Strict enforcement that prevents installation of non-registry servers is not yet available

For the highest level of security, you can disable MCP servers in Copilot until strict enforcement is available.

How MCP policies apply to your users

MCP policies apply to all users who receive Copilot seats from the organization or enterprise where the policy is configured.

When a policy is enabled or disabled at the enterprise level, it is automatically applied to all child organizations and their members, and cannot be overridden by those organizations.

When an enterprise lets child organizations configure their own MCP policies, each organization must choose its own registry URL and enforcement settings. This allows teams with different security or compliance needs to choose the configuration that works best for them.

Support for MCP policies

Surface	Registry display	Allowlist enforcement
Copilot CLI
Copilot coding agent
Eclipse
JetBrains
Visual Studio
VS Code
VS Code Insiders
Xcode

Configuring the MCP allowlist policy for an enterprise

1. In the top-right corner of GitHub, click your profile picture.

2. Depending on your environment, click Enterprise, or click Enterprises then click the enterprise you want to view.

3. At the top of the page, click AI controls.

4. In the sidebar, click MCP.

5. Ensure MCP servers in Copilot is set to Enabled everywhere.

6. In the MCP Registry URL section, enter the URL of your specification-compliant MCP registry, then click Save.

7. In the Restrict MCP access to registry servers section, select one of the following from the dropdown menu:

   • Allow all: No restrictions. All MCP servers can be used.
   • Registry only: Only servers from the registry may run.

   Your chosen policy will immediately apply to developers in your enterprise.

Configuring the MCP allowlist policy for an organization

1. In the upper-right corner of GitHub, click your profile picture, then click Organizations.

2. Next to the organization, click Settings.

3. In the sidebar, under "Code, planning, and automation", click Copilot, then click Policies.

4. Under "Features" ensure MCP servers in Copilot is set to Enabled.

5. In the MCP Registry URL (optional) field, enter the URL of your specification-compliant MCP registry.

6. Click Save.

7. Next to Restrict MCP access to registry servers, select one of the following from the dropdown:

   • Allow all: No restrictions. All MCP servers can be used.
   • Registry only: Only servers from the registry may run.

   Your chosen policy will immediately apply to developers in your organization.

How are MCP allowlists enforced?

GitHub uses the following strategies for MCP allowlist enforcement.

Local servers

MCP allowlist enforcement applies to local MCP servers as well. When "Registry only" is configured, local servers must be included in the registry to be allowed.

Including local servers in your registry:

• Local servers must be listed in your registry with their correct server ID
• The server ID must match exactly between the registry entry and the installed server
• Consult the server's documentation or manifest for its canonical ID
• For consistent deployment across your organization, provide installation instructions that ensure users install the server with the expected ID

Policy resolution for users with multiple seats

MCP allowlist enforcement is always tied to the organization or enterprise that assigns the GitHub Copilot seat. If a user has multiple seats (for example, from several organizations or from both an enterprise and its child organizations), GitHub automatically resolves conflicts and applies a single active policy.

The resolution logic is:

1. Scope: Policies set by a parent enterprise override those set by an organization. Enterprise policies trickle down to all organizations and members within that enterprise.
2. Enforcement strictness: Registry only outranks Allow all.
3. Recency of registry upload: If two policies have the same scope and strictness, the most recently uploaded registry wins.
4. Tie-breaker: If all else is equal, the lowest internal ID wins.

Setting up an MCP registry

If you don't already have an MCP registry configured, there are a few different ways you can create one depending on your needs.

Self-hosting a registry

At its core, a registry is a set of HTTPS endpoints that serve details about the included MCP servers. To make your registry reachable, you can take any of the following paths:

• Fork and self-host the open-source MCP Registry
• Run the open-source registry locally using Docker
• Publish your own custom implementation

To get started with the open-source registry, see the MCP Registry Quickstart in the github/modelcontextprotocol repository.

A valid registry must:

• Be reachable over HTTPS
• Support URL routing

To successfully configure your registry, you need to implement the following endpoints:

• GET /v0.1/servers: Returns a list of all included MCP servers
• GET /v0.1/servers/{serverName}/versions/latest: Returns the latest version of a specific server
• GET /v0.1/servers/{serverName}/versions/{version}: Returns the details for a specific version of a server

Example registry format

Your registry must return a JSON response following the v0.1 MCP registry specification:

{
  "servers": [
    {
      "_meta": {
        "io.modelcontextprotocol.registry/official": {
          "status": "active",
          "publishedAt": "2025-09-01T00:00:00Z",
          "isLatest": true
        }
      },
      "server": {
        "$schema": "https://static.modelcontextprotocol.io/schemas/2025-10-17/server.schema.json",
        "name": "io.github.modelcontextprotocol/server-github",
        "description": "Official GitHub MCP server for repository management, issues, and pull requests.",
        "version": "1.0.0",
        "packages": [
          {
            "registryType": "npm",
            "identifier": "@modelcontextprotocol/server-github",
            "version": "1.0.0",
            "transport": { "type": "stdio" }
          }
        ],
        "remotes": [
          {
            "type": "http",
            "url": "https://api.githubcopilot.com/mcp/"
          }
        ]
      }
    },
    {
      "_meta": {
        "io.modelcontextprotocol.registry/official": {
          "status": "active",
          "publishedAt": "2025-09-01T00:00:00Z",
          "isLatest": true
        }
      },
      "server": {
        "$schema": "https://static.modelcontextprotocol.io/schemas/2025-10-17/server.schema.json",
        "name": "io.github.modelcontextprotocol/server-filesystem",
        "description": "MCP server for secure file system operations with configurable access controls.",
        "version": "1.0.0",
        "packages": [
          {
            "registryType": "npm",
            "identifier": "@modelcontextprotocol/server-filesystem",
            "version": "1.0.0",
            "transport": { "type": "stdio" }
          }
        ]
      }
    }
  ],
  "metadata": {
    "count": 2,
    "nextCursor": null
  }
}

Required fields:

• server.name: Reverse DNS identifier for the MCP server
• server.description: Brief summary of server functionality
• server.version: Version string
• server.packages: Required if the server provides a local installation (registryType, identifier, version, transport)
• server.remotes: Required if the server provides hosted endpoints (type, url)

Optional fields that provide additional metadata:

• _meta: Registry-managed metadata (status, publishedAt, isLatest)
• metadata: Pagination details (count, nextCursor)
• Additional publisher-provided fields may appear under server._meta

Support for v0.1

To avoid breaking changes to your registry in the future, you should implement v0.1 of the MCP registry specification. Be aware that v0.1 is currently only supported in VS Code Insiders, with other surfaces adding support soon. See the following table for more details.

Surface	v0.1 support date
VS Code Insiders	Oct 23, 2025
Visual Studio	Nov 5, 2025
VS Code	Nov 14, 2025
Eclipse	Dec 2025
JetBrains IDEs	Dec 2025
Xcode	Dec 2025

Using Azure API Center as a registry

For enterprises that want a dynamic and fully managed option, Azure API Center can be used as an MCP registry. It provides governance features, discovery UI, and integration with existing API catalogs.

1. Go to the Azure API Center portal.
2. Create a new API Center instance (or reuse an existing one).
3. Add your MCP servers as APIs, including their manifests and metadata.
4. Publish your API Center instance.
5. Copy the API Center endpoint URL—this becomes your MCP registry URL.
6. Paste this URL into the MCP Registry URL (optional) field in your GitHub Enterprise or organization settings.

For more information, see Register and discover remote MCP servers in your API inventory in the Azure API Center Documentation.