How to find, install, and manage MCP servers with the GitHub MCP Registry

MCP servers get a canonical home on GitHub

Model Context Protocol (MCP) servers are how developers connect tools, APIs, and workflows to AI systems. Until recently, finding them meant digging through scattered registries and outdated listings. The GitHub MCP Registry consolidates discovery, installation, and management of MCP servers into one place on GitHub.

The registry currently lists 44 MCP servers, including Playwright for browser automation, GitHub's own server with over 100 API tools, Context7, MarkItDown (Microsoft), Terraform (HashiCorp), and partner offerings from Notion, Unity, Firecrawl, and Stripe. Servers can be browsed by tags, popularity, or GitHub stars.

One-click installation from VS Code

Installing a server from the registry is designed as a one-click operation in VS Code or VS Code Insiders. To install Playwright, for example, navigate to its page in the registry, click Install in VS Code, and VS Code launches with a pre-filled configuration. You accept or adjust optional parameters—such as storage paths—and the server is ready for agentic workflows.

For remote MCP servers like GitHub's, OAuth handles authentication during install, so there are no tokens or secrets to manage manually.

Publishing your own server

If you maintain an MCP server, the registry provides a CLI-based publishing flow.

Install the MCP Publisher CLI

On macOS/Linux/WSL, Homebrew is the recommended installation method:

brew install mcp-publisher

Alternatively, download the prebuilt binary:

"https://github.com/modelcontextprotocol/registry/releases/download/latest/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher && sudo mv mcp-publisher /usr/local/bin/

Initialize server metadata

From your server's source directory, run:

cd /path/to/your/mcp-server
mcp-publisher init

This generates a server.json file:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-09-29/server.schema.json",
  "name": "io.github.yourname/your-server",
  "title": "Describe Your Server",
  "description": "A description of your MCP server",
  "version": "1.0.0",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "your-package-name",
      "version": "1.0.0",
      "transport": { "type": "stdio" }
    }
  ]
}

Prove package ownership

You must add metadata that links the registry entry to your published package:

• NPM: add an "mcpName" field to package.json:

{
  "name": "your-npm-package",
  "mcpName": "io.github.username/server-name"
}

• PyPI/NuGet: add a verification line to your README:

mcp-name: io.github.username/server-name

• Docker: add a label to your Dockerfile:

LABEL io.modelcontextprotocol.server.name="io.github.username/server-name"

Authenticate and publish

For GitHub-based namespaces (io.github.*), authentication opens a browser for OAuth login:

mcp-publisher login github

Custom domains (com.yourcompany/*) require DNS verification, documented in the official publishing guide. Once authenticated, publish:

mcp-publisher publish

Confirm that the server is discoverable in the registry:

curl "https://registry.modelcontextprotocol.io/v0/servers?search=io.github.yourname/your-server"

After publication, email [email protected] to request inclusion in the registry.

When filling in server.json, note that remote HTTP endpoints go in a "remotes" array so cloud-based servers are supported:

"remotes": [
  {
    "type": "streamable-http",
    "url": "https://yourdomain.com/yourserver"
  }
]

A server may list both "packages" and "remotes" for hybrid deployments. Useful namespace conventions: io.github.username/* for GitHub auth, or com.yourcompany/* for DNS verification. Reference implementations include airtable-mcp-server (npm/Docker/MCPB), time-mcp-nuget, and time-mcp-pypi.

Automate with GitHub Actions

A workflow file at .github/workflows/publish-mcp.yml can publish on every tagged release to both your package registry and the MCP registry:

name: Publish to MCP Registry
on:
  push:
    tags: ["v*"]

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # For OIDC
      contents: read

    steps:
      - uses: actions/checkout@v5

      # (Edit these for your package type)
      - name: Setup Node.js
        uses: actions/setup-node@v5
        with:
          node-version: "lts/*"
      - name: Install dependencies
        run: npm ci
      - name: Build and test
        run: |
          npm run build --if-present
          npm run test --if-present
      - name: Publish to npm
        run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

      # MCP publishing (works for all package types)
      - name: Download MCP Publisher
        run: |
          curl -L "https://github.com/modelcontextprotocol/registry/releases/download/latest/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher
      - name: Publish to MCP Registry
        run: |
          ./mcp-publisher login github-oidc
          ./mcp-publisher publish

      # Optional: keep server.json version in sync with git tag
      - run: |
          VERSION=${GITHUB_REF#refs/tags/v}
          jq --arg v "$VERSION" '.version = $v' server.json > tmp && mv tmp server.json

Trigger it with a version tag:

git tag v1.0.0
git push origin v1.0.0

Once published, downstream registries pick up updates automatically. Hosting the server code in a public GitHub repository signals verified ownership, and tags in server.json help developers discover the server by category.

Enterprise governance with allow lists

For organizations that need control over which MCP servers developers can install—particularly when servers interact with sensitive data—GitHub supports registry-level allow lists.

1. Set up an internal registry that follows the MCP API spec (registry plus HTTP endpoint).
2. Populate it with vetted internal and external MCP servers.
3. Point GitHub Enterprise settings to that registry endpoint.
4. MCP-aware surfaces, starting with VS Code, enforce the allow list automatically.

For example, an internal registry at https://internal.mybank.com/mcp-registry returns an approved list:

{
  "servers": [
    {
      "name": "github.com/github/mcp-server",
      "version": "1.0.0"
    },
    {
      "name": "github.com/microsoft/markitdown-mcp",
      "version": "2.1.0"
    },
    {
      "name": "internal.mybank.com/mcp-servers/custom-tools",
      "version": "1.5.0"
    }
  ]
}

When a developer attempts an install in VS Code, GitHub checks the registry endpoint and permits only servers from the approved list. This governance model allows security scans, partnership vetting, and compliance work while still giving developers access to needed tools.

Working the registry like a power user

• Assess quality quickly: GitHub stars and verified orgs (Microsoft, HashiCorp) are strong signals of legitimacy.
• Test before publishing: Use the MCP Inspector to catch issues early.
• Combine agents: Copilot coding agent ships with GitHub and Playwright MCP servers preloaded, enabling pull requests with web-app screenshots for UI-heavy work.
• Tame tool overload: VS Code is rolling out semantic tool lookups, so only tools relevant to the prompt surface, rather than flooding context with dozens of options from large servers like GitHub's.

Looking further ahead, GitHub expects self-publication to open up in the coming months, additional IDE support, expanded enterprise governance features for regulated industries, and bundling of GitHub MCP server tools into use-case-driven flows such as "analyze repository + open pull request."