GitHub MCP Registry explained: Discovering and vetting MCP servers

TL;DR: The GitHub MCP Registry (the common name for the official MCP Registry, which is governed by a community working group under the MCP project's charter rather than owned by GitHub) is a discovery and metadata layer for MCP servers, not a security guarantee. GitHub does not verify the safety of submitted servers. The schema enforces only three mandatory fields (name, version, description). Vetting means going beyond that: confirm the listing includes packages or remotes (optional at the schema level, but without one clients have nothing to connect to), confirm transport is set inside each package, then review operational signals like commit recency, dependency health, and transport security. Teams adopting the registry need a governance layer for credential isolation, policy enforcement, and audit logging before connecting servers to production agents.

Your team found an MCP server on GitHub that does exactly what your agent needs. Before you connect it: what does "listed on GitHub" actually verify?

Not much. The MCP Registry, commonly called the GitHub MCP Registry, is a centralized metadata repository governed by a community working group under the MCP project's charter, designed to solve the discovery problem for publicly accessible MCP servers. It does not host source code, execute security audits, or validate runtime behavior. What it provides is a standardized metadata layer pointing to external registries like npm, PyPI, Docker Hub, and GitHub, making servers comparable through a structured schema.

This distinction matters because security researchers have documented DNS rebinding attacks against MCP servers, which can bypass local network protections and expose sensitive capabilities remotely in servers using HTTP-based transports. Vetting servers before connection is not optional.

This article covers how the registry works, how to submit servers, what metadata is required, and how to vet third-party servers before they touch production agent traffic.

How the GitHub MCP Registry powers tool discovery

The GitHub MCP Registry is a metaregistry: a centralized index storing metadata about MCP servers rather than the servers themselves. Querying it returns structured metadata describing where a server is hosted, what transport it uses, and what capabilities it exposes. The actual code lives elsewhere, typically on npm, PyPI, Docker Hub, or a GitHub repository.

Before the registry, discovery meant searching GitHub manually and hoping maintainers documented their server.json manifests correctly. The registry standardizes discovery by enforcing a common metadata schema and providing a single API endpoint. It uses namespace authentication to prevent spam: publishers verify ownership through GitHub, DNS, or HTTP challenges before submitting. This validates publisher identity but says nothing about server security, maintenance status, or runtime behavior.

MCP Registry vs. standard package managers

The registry differs from package managers like npm or PyPI in one critical way: it does not host binaries or source code, only references to packages hosted elsewhere.

The registry uses string-based version identifiers in YYYY-MM-DD format indicating the last date backwards-incompatible changes were made, so clients and servers built on different versions can still work together. When an agent needs a tool, it queries the registry for servers matching the required capability, retrieves the metadata, then connects at the location specified in the packages or remotes field.

How the GitHub registry works

The registry exposes a REST API returning JSON metadata. You publish using the mcp-publisher CLI after authenticating with GitHub OAuth.

Submission starts with a server.json manifest describing your server's name, location, execution instructions, and capabilities. The 2025-12-11 schema caps title and description at 100 characters each, and the name field must match namespace/server using only letters, digits, dots, dashes, and underscores. After authentication, you run mcp-publisher publish from the directory containing your server.json. If the schema validates, the registry indexes the metadata. The registry does not execute, sandbox, or test the server code, so what happens when someone connects is outside its scope.

How the MCP Registry manages data

The MCP Registry runs as a public dataset with namespace-based access control, overseen by a working group of maintainers from multiple organizations rather than by GitHub alone. Per the official charter, current working group members are Stacklok, PulseMCP, TeamSpark, and Ravenmail, while Anthropic and GitHub are listed as emeritus members who have stepped down. Publishers authenticate through GitHub OAuth and can only submit under namespaces they control, such as io.github.yourusername/* or com.yourdomain/* after DNS verification. Data is queryable through a public API at registry.modelcontextprotocol.io. Namespace authentication and package ownership verification prevent spam but only validate publisher identity, not server security.

GitHub's curated registry (a separate, smaller list of recommended servers) sets a higher bar with stability, documented security practices, and active maintenance, but even curation is not a security audit.

Automating GitHub MCP server registration

Submitting a server means shipping your package or remote endpoint first, writing a valid server.json manifest, authenticating through GitHub OAuth, and publishing through the mcp-publisher CLI. The registry enforces schema validation at submission time.

MCP Registry schema and setup guide

The only schema-enforced mandatory fields are name, version, and description. Servers point clients to their code through either packages (for npm/PyPI/container distributions) or remotes (for hosted HTTP endpoints). Both are optional at the schema level, so a server with neither would publish successfully but be useless, since nothing would tell clients where to find it. In practice, you will always include one. Everything else is optional but recommended. Example manifest:

{
  "name": "io.github.exampleorg/github-tools",
  "version": "1.2.0",
  "description": "MCP server for GitHub repository and issue management",
  "packages": [
    {
      "registryType": "oci",
      "identifier": "ghcr.io/exampleorg/github-tools:v1.2.0",
      "transport": {
        "type": "stdio"
      }
    }
  ]
}

Inside each packages entry, the transport field specifies how clients connect: stdio (local processes) or streamable-http (HTTP-based request-response). It is required within each package object, not at the root of server.json. The older HTTP+SSE (sse) transport was deprecated in March 2025, as listed in the MCP deprecated features registry.

Step-by-step registry submission flow

Publishing follows a deterministic sequence:

1. Ship your package to npm, PyPI, Docker Hub, or GitHub Container Registry, or deploy your remote HTTP endpoint.

2. Initialize your manifest using mcp-publisher init, which generates a template server.json file.

3. Edit the manifest with your server's metadata, and confirm the name follows the namespace/server pattern and descriptions stay under 100 characters.

4. Authenticate using mcp-publisher login, which opens a browser-based GitHub OAuth flow authorizing you to publish to the io.github.<your-username>/* namespace.

5. Validate locally using mcp-publisher validate server.json to surface schema errors (descriptions exceeding 100 characters, invalid name patterns) before submission.

6. Publish using mcp-publisher publish. The CLI submits your server.json to the registry API, which validates and indexes it.

7. Verify publication by querying the public registry API for your server name and confirming the listing appears in search results. Schema validation errors are the most common blocker, particularly the 100-character description limit and the strict name pattern.

GitHub registry submission guidelines and eligibility rules

To publish under a custom domain namespace like com.example/server, you must prove control through a DNS TXT record or HTTP challenge; for io.github, GitHub OAuth suffices. The registry will reject your submission if it fails schema validation or namespace verification:

• Invalid name field: Must match namespace/server with only alphanumeric characters, dots, dashes, and underscores.

• Oversized metadata: Titles and descriptions capped at 100 characters each.

• Unverified namespace: Publishing under a namespace you do not control fails at authentication. For GitHub's curated registry, the bar includes demonstrated stability, documented security practices, active maintenance, and responsive issue management. Inclusion still does not imply a formal security audit.

Data fields in GitHub MCP registries

The metadata schema is the contract between publishers and consumers: every server exposes the same mandatory fields, making servers comparable and enabling automated tooling to evaluate them.

Defining server metadata fields

Optional metadata fields improve discoverability and help consumers evaluate fit:

• transport: Connection protocol (stdio or streamable-http), set inside each packages entry rather than at the root, and required there once packages is present.

• repository: Source code location, typically a GitHub URL.

• homepage: Typically a link to documentation or a project page.

• license: SPDX license identifier.

Registry versioning and compatibility

MCP uses date-based versioning (YYYY-MM-DD) indicating the last backwards-incompatible change. This lets clients and servers negotiate compatible versions at connection time. Every MCP request declares the MCP version it implements via the io.modelcontextprotocol/protocolVersion key in its _meta field.

If the server does not support the requested version, it responds with an UnsupportedProtocolVersionError listing supported versions, and the client retries with a mutually supported one. Clients and servers may support multiple protocol versions simultaneously, reducing breaking changes as the protocol evolves.

Schema validation rules

The registry enforces validation at submission time using a linter:

• Field length limits: Titles and descriptions capped at 100 characters.

• Name pattern matching: name must match namespace/server with restricted character sets.

• Required field presence: All mandatory fields must be present and non-empty. You can run validation locally using mcp-publisher validate to catch schema errors before submitting.

How MCP servers flow from registry to runtime

The path from discovering a server to executing tool calls involves several decision points. The registry provides metadata; connecting requires evaluating trust, configuring transport, and enforcing runtime policies.

Evaluating GitHub MCP server quality

A registry listing tells you a server exists, not whether it is maintained, whether dependencies are current, or whether its transport is configured securely. Key quality indicators:

• Commit recency: A long stretch without commits suggests abandonment.

• Issue response time: Maintainers who stop responding to new issues are a warning sign, especially when response times keep getting longer.

• Dependency health: Stale dependencies with known vulnerabilities create risk.

• Release cadence: Erratic releases or long gaps signal inconsistent maintenance. Tools like TrustOSS score GitHub repository health across activity, maintenance, community, documentation, and maturity signals, with dependency health covered in a separate deep scan, so check the tool's current metric set before relying on its score. For servers using HTTP transport, additional review is required: HTTP servers that do not enforce strict verification of Origin and Host headers are vulnerable to DNS rebinding attacks.

Setting up your MCP Registry connection

For stdio servers, the packages field points to a package or container running locally; you install it and configure your agent to spawn the process. For remote HTTP servers, the remotes field contains a URL, and you configure your agent to connect using the specified transport. Remote servers require network access and often involve OAuth or API key authentication.

The registry metadata does not handle authentication, which means every remote server connection requires OAuth flow implementation, encrypted token storage, token refresh, and scope enforcement. Building that plumbing in-house for each enterprise SaaS tool typically consumes months of engineering time before the agent performs a single useful action. Composio's managed layer spans 1,500+ business systems, with more than 50,000 agent-ready tools and over 1 million connected accounts.

Executing verified MCP server connections

Without a policy enforcement layer, the agent can invoke any tool the server exposes with whatever permissions the server's OAuth token grants. Prompt-level guardrails are soft instructions that a sufficiently creative user input can override, creating accountability and safety risk in production. Policy-as-code enforcement evaluates access restrictions in the request path before any model interaction, so an admin's decision to disable delete actions holds regardless of what the prompt contains.

Composio's policy-as-code enforcement evaluates access rules before any model interaction. An admin can disable the delete action for a Slack integration, and the agent cannot delete messages even if the prompt suggests it. Every tool call is logged with user, team, tool, action, and outcome, including denied calls, creating a complete audit trail of every tool call.

Security requirements for GitHub MCP Registry tools

Criteria for MCP server audits

Before connecting a registry-listed server, verify:

MCP servers using HTTP transport are prone to DNS rebinding attacks when they do not enforce strict verification of both Origin and Host headers, allowing attackers to bypass same-origin policies and potentially gain unauthorized access to sensitive data.

The bash-vet-mcp tool provides command-level security validation for servers that execute shell commands, vetting LLM-emitted shell commands before execution using 30 detection rules across destructive file operations, package managers, system commands, database operations, git, network, exfiltration, and privilege escalation. It returns a verdict (CLEAN, CAUTION, REVIEW, BLOCK, or UNVERIFIED) plus a risk score and per-finding details.

Evaluating GitHub MCP server dependencies

Dependency health is a leading indicator of maintenance status. When vetting a server, check for known vulnerabilities using npm audit or pip-audit, verify dependency pinning (floating versions introduce non-determinism), and review issue response time for security-related reports. Slow maintainer response, unresolved security issues, and stale dependency management all suggest the project may no longer be actively maintained in any security-relevant sense.

Securing registry authentication

Servers requiring OAuth or API keys introduce credential management overhead: OAuth flow implementation (redirect URIs, token exchange, scope negotiation), encrypted token storage, automated token refresh, and scope enforcement. Each OAuth implementation becomes a maintenance obligation when upstream APIs change authentication models.

Identifying abandoned MCP projects

Abandoned projects create operational risk because security patches and dependency updates stop arriving. The two commit-recency thresholds in this article measure different things: a last commit within 90 days is the healthy baseline for an active project (see the audit criteria above), while 180+ days without commits on a previously active project signals abandonment. Projects between 90 and 180 days warrant a closer look rather than an automatic rejection. Other signals include unresponsive maintainers (issues open 90+ days), archived repositories, and stale CI/CD. Bus factor, meaning the number of maintainers whose departure would stall the project, matters too: if only one person can cut a release, the project is fragile, and for load-bearing infrastructure that kind of single-maintainer dependency is a red flag.

When you identify an abandoned server, your options are to fork and maintain it yourself, find an alternative, or build the integration in-house.

Reducing integration overhead with the registry

The registry solves discovery but not execution. Teams adopting the registry without an execution layer create a new maintenance surface: every server connection still requires planning, routing, scoped auth, retries, recovery, and verification, plus credential storage and audit logging. What agents need is one governed path to act across business systems, and the registry metadata alone does not provide it.

Public vs. private MCP server hosting

The public GitHub MCP Registry is the default discovery layer. Teams that need to restrict discovery to internal servers can host a private registry and restrict access to listed servers. Hosting a private registry means maintaining the service itself (uptime, backups, schema validation) as an ongoing operational cost for your team. The alternative is the public registry with a governance layer that enforces policies at runtime, avoiding the maintenance burden while still controlling which servers agents can connect to.

Registry compliance and risk control

SOC 2 audits require access restricted to minimum necessary permissions, monitoring for anomalies in system activity, and documented change management controls. Auditors test these areas through the Common Criteria control families: CC6 covers logical access, CC7 covers system operations and monitoring, and CC8 covers how changes get authorized and deployed. Registry metadata supports some requirements: access scope documentation, source code references for supply chain verification. But metadata alone does not enforce controls.

Enforcement requires a governance layer between agent and server evaluating policies before tool calls execute. Composio's centralized audit logging records every tool call including denied actions, giving your team a complete audit trail to draw on during audits.

Deploying local MCP server mirrors

Some teams run local mirrors of vetted MCP servers rather than connecting to remote endpoints, reducing external dependencies and gaining full runtime control: pull the server image, host it in your own registry, and configure agents to connect to the local mirror.

The trade-off is maintenance. When the upstream server releases a security patch, you pull, test, and redeploy. For a few critical servers this is manageable; for a large catalog, overhead compounds. Composio does not maintain mirrors of third-party MCP servers on your behalf, so that patching work stays with your team. Composio's maintenance coverage applies to its own 1,500+ managed integrations, a separate category, where provider API maintenance, token refresh edge cases, and scope updates are handled by Composio rather than your engineering team.

Assessing portability of MCP servers

MCP servers following the protocol specification are portable across hosting environments. Servers with hardcoded URLs, local filesystem dependencies, or state that must persist between connections face constraints. Servers that hold no state and use stdio transport are the most portable.

How Composio handles this: Every server that requires OAuth or API keys puts credentials at risk of ending up in application code or the LLM context, where prompt injection or model output can expose them, and any access rule left to the model can be overridden by a sufficiently creative prompt. Composio is action infrastructure for knowledge work agents, built to remove that exposure: one SDK your agent uses to act across the business systems it needs to reach, learning from every run. Your agent calls a tool, Composio resolves the credential inside an isolated runtime, and the agent receives only the response. Credentials stay isolated from the LLM context and your application code, and policies set by admins are evaluated in the request path as code rather than left to the model.

Composio holds SOC 2 Type II and ISO/IEC 27001:2022 certifications, documented in its trust center. The platform processes more than 1B tool calls. Skills distilled from that volume make repeat tasks 30% more accurate on 2x fewer tokens, so your agent starts ahead on day one.

If you are evaluating MCP servers for production use and need to answer enterprise security questions about credential storage, access controls, and audit trails, book a call to walk through your security requirements before the next enterprise review. Teams that prefer to test first can start on the free tier with 100,000 tool calls per month and run a first integration without a sales call.

FAQs

Can I submit a private MCP server to the GitHub registry?

No. The public registry is designed for discovery of publicly accessible servers and does not accept private servers, meaning servers only accessible to a narrow set of users. For internal-only servers, host a private registry or use managed configuration files with restricted access, which provides stronger enforcement than registry-level controls.

How do I update metadata after a server is listed?

Update your server.json file with the new metadata and republish using mcp-publisher publish. The registry indexes the updated metadata, replacing the previous version.

What happens when an upstream MCP server changes its API?

Breaking changes require the server to publish a new protocol version. Your client negotiates compatibility at connection time using the UnsupportedProtocolVersionError response. If the server drops support for your client's version, you must upgrade your client or pin to an older server version.

Does GitHub verify security of submitted servers?

No. GitHub verifies publisher identity through namespace authentication but does not audit server security, runtime behavior, or maintenance status. Vetting is the responsibility of the team connecting the server.

Can I fork and modify a registry-listed server?

The registry listing itself does not grant forking rights, so check the license in the server's source repository before proceeding. If the license permits it, you would publish the forked server under your own namespace (e.g., io.github.yourusername/forked-server) and maintain it independently.

Key terms glossary

Model Context Protocol (MCP): An open protocol for connecting AI agents to external tools and data sources through a standardized interface. MCP servers expose tools that agents invoke using the protocol.

MCP Registry: A centralized metadata repository for discovering publicly accessible MCP servers. Stores metadata but does not host server code.

server.json: The manifest file describing an MCP server's metadata, including name, transport, location, and capabilities. This file is required for registry submission and validated against the schema at publish time.

Namespace authentication: Verifying ownership of a registry namespace (e.g., io.github.username or com.example) through GitHub OAuth, DNS TXT records, or HTTP challenges before publishing servers. This validates publisher identity but not server security.

DNS rebinding: An attack that bypasses same-origin policies by manipulating DNS responses, allowing malicious websites to make requests to internal network resources. MCP servers using HTTP transport are vulnerable if they do not validate Origin and Host headers.

Policy-as-code enforcement: Access control rules evaluated in the request path before the model is involved, enforced at the infrastructure layer rather than through prompt instructions. This makes restrictions structurally enforced rather than prompt-dependent.

Credential isolation: Storing credentials in a centralized vault with encryption, isolated from the LLM context and application code so credentials never reach the model or appear in agent memory. This prevents credential leakage through prompt injection or model output.

Transport protocol: The communication mechanism between an MCP client and server: stdio (local process) or streamable HTTP (request-response over HTTP).

Tool call: A single invocation of a tool exposed by an MCP server, initiated by an AI agent and logged with user, team, tool, action, and outcome for audit purposes. Audit logs include denied calls, not just successful ones.