Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The MCP Server Registry is the official Model Context Protocol catalog and API for discovering publicly available MCP servers. You can use its searchable directory to find server listings; maintainers can publish through the documented workflow and publisher CLI. It is a discovery source, not a guarantee that a listed server is safe, compatible with every client, or maintained.

What the MCP Server Registry is—and what it is not

The Model Context Protocol (MCP) Registry is an open catalog and API for publicly available MCP servers. The official MCP project launched it in preview on September 8, 2025, to make servers easier to discover and give downstream directories a common upstream source. The production site provides search and links to API reference material.

Think of the registry as a directory of server metadata. It helps a client or person find a server and learn how its publisher describes it; it does not itself make a server available to your AI client, run the server for you, or certify the server’s code. A registry listing is a starting point for evaluation, not an endorsement.

The project is open source. Other public marketplaces can consume registry data and add their own organization, filters, compatibility information, or curation. Private enterprise sub-registries can also use it as an upstream source while applying their own privacy and security criteria. These layers serve different needs: the official registry is foundational discovery, while a marketplace may add a more specialized selection or policy workflow.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How to find an MCP server

  1. Open the official registry’s discovery interface. Search for the capability or integration you need. The directory is for public servers; private enterprise listings may instead be exposed through an organization’s own sub-registry.
  2. Read the listing as publisher-provided metadata. Check the stated purpose, publisher identity, source repository, and any instructions or requirements shown. Do not assume that a listing’s presence means a project is actively maintained or compatible with your particular client.
  3. Follow the listing to its source and inspect it. Review the repository and its recent maintenance activity, the permissions the server requests, and how it communicates and authenticates. Confirm that those requirements make sense for the task and the data you plan to expose.
  4. Check the target client’s requirements. A registry entry helps with discovery; client compatibility and configuration are still client-specific. Use the server publisher’s instructions and your client’s current documentation before connecting.
  5. Use a specialized marketplace when its extra controls matter. If you need compatibility filters, an organization-approved allowlist, or policy checks, compare what a downstream or private registry actually adds rather than assuming all directories provide the same safeguards.

Directory contents can change. No stable server-count figure is established here, so a live count should not be treated as a durable measure of registry coverage or quality.

How to publish a server

Maintainers publish through the registry’s documented workflow and publisher CLI. The repository documentation describes namespace validation, supported verification methods, and examples such as io.github.domdomegg/my-cool-mcp. That example illustrates a namespace tied to a GitHub identity; it is not a name to copy unless you control the relevant identity or domain.

  1. Choose a namespace you can prove you control. The registry validates namespaces. The documented model requires a publisher to establish the relevant GitHub identity or control of a domain; choose an identifier that represents your project and that you can continue to verify.
  2. Select an available authentication or verification route. Documented methods are GitHub OAuth, GitHub OIDC from GitHub Actions, DNS verification, and HTTP verification. Which route is appropriate depends on where you maintain and publish the project.
  3. Use the publisher CLI and follow the current repository workflow. The repository includes a publisher command and validation tools. The current CLI syntax and required metadata fields are not specified in the project documentation; use the versioned project documentation rather than copying an unverified command or assuming a schema.
  4. Validate the entry and keep its information accurate. Treat metadata as operational information for people deciding whether to connect your server. Keep ownership, source links, requirements, and descriptions aligned with the actual project.
  5. Publish through the documented process and maintain the listing. Namespace verification establishes a connection to a publisher identity or domain; it does not substitute for ongoing maintenance, security review, or clear release practices.

The registry repository records an October 24, 2025 status update announcing a temporary API freeze at v0.1 while integrations informed future versions. That is a dated status, not a guarantee of the current version in September 2026. Before scripting a publishing workflow or integrating against the API, check the current version and instructions in the official project materials.

Is the official MCP Registry safe?

It is useful as an official discovery source, but a listing is not a safety certification. In its September 8, 2025 launch announcement, the MCP team said server information is self-reported for downstream consumers to process. The announcement also described community flagging for spam, malicious code, and impersonation, and the ability for maintainers to denylist entries and remove them from public access. Those are moderation mechanisms; they cannot establish that every listing has been independently audited or that a server remains safe after publication.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Before connecting a server, evaluate it at the source:

  • Publisher and namespace: Does the repository or publisher identity correspond to the organization or maintainer named in the listing? Be alert to impersonation or a similarly named project.
  • Code and maintenance: Is the source available, does its activity look consistent with a project that is maintained, and are releases or changes explained? A listing alone does not answer these questions.
  • Permissions and data access: Understand what files, services, credentials, or user data the server can reach. Give it only access that is appropriate for the task.
  • Transport and authentication: Confirm how the server communicates and authenticates, and whether that arrangement is suitable for your environment. Do not send credentials to an endpoint you have not verified.
  • Organization policy: For workplace use, follow your organization’s review and approval process. A private sub-registry may add controls, but the controls and their scope depend on the organization operating it.

The preview announcement warned that the service could change before general availability, including breaking changes or data resets. That warning is specific to the preview period; check current project notices for the present service status rather than treating the preview warning as a statement that a reset is now planned.

Registry, marketplace, or private catalog?

These names can describe different layers of discovery. The comparison below reflects the roles described by the MCP project; it does not imply that every downstream directory implements every possible extra control.

Option Role What to verify
Official MCP Server Registry Foundational public catalog and API for server discovery; launched in preview September 8, 2025. Publisher-provided metadata, namespace ownership, project status, and current API version.
Public client marketplace or downstream directory May ingest and augment upstream registry data with its own organization, client-oriented filters, or curation. Which data is inherited, how often it is refreshed, and which compatibility or policy checks are actually performed.
Private enterprise sub-registry Can use the official registry as an upstream source while applying organization-specific privacy and security criteria. Who approves entries, what data is synchronized, and which controls apply to employees or clients.

When selecting a directory, compare provenance, metadata freshness, namespace and moderation practices, API versioning, client compatibility, deployment model, and curation. The word “marketplace” alone does not tell you whether entries are independently reviewed; look for an explicit description of its process.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Can you run the registry locally?

Yes. The project repository documents local and self-hosted development paths using Docker, Go, PostgreSQL-backed make dev-compose, and pre-built images from GitHub Container Registry with versioned tags. It also includes API models, validation tools, integration tests, and a publisher command.

Those options serve development and deployment needs, but the repository summary does not establish a single recommended production topology or a complete set of deployment commands. Follow the current repository instructions for prerequisites, configuration, image tags, database setup, and upgrades. In particular, distinguish a local development stack from a production service: deployment, access control, backups, monitoring, and update procedures depend on the environment you operate.

  • For a local development setup: use the documented Docker or Go workflow and the PostgreSQL-backed development composition where appropriate.
  • For a container-based deployment: select a versioned image tag from the project’s published container images and follow the matching configuration instructions; avoid assuming an unversioned tag is reproducible.
  • For API integrations: use the current API reference and check its version. The v0.1 freeze announcement is dated October 24, 2025, and does not establish the version or compatibility guarantees in force now.
  • For publishing automation: use the documented GitHub OIDC route if it fits your workflow, or another supported verification method. Confirm the current CLI and authentication instructions before adding a publishing step to CI.

What the registry does not tell you

The registry can improve discovery and make metadata available through a common source, but it cannot replace evaluation of the software or of the directory that presents it. A reader should not infer a server count, adoption level, security certification, review standard, API stability guarantee, or a particular refresh interval from the existence of the catalog. For any of those questions, look for a current, explicit statement from the registry operator or the marketplace being evaluated.

Similarly, an upstream listing and a downstream listing may differ. A client marketplace can augment upstream metadata, apply curation, or add policy controls, but the amount and quality of that work are specific to that marketplace. Check its stated process rather than carrying assumptions from the official registry to every directory that consumes its data.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Or skip the browser setup

For developers building a workflow that needs a website screenshot alongside MCP-based tools, ScreenshotNeo is a separate website screenshot API and MCP server made by Yorker Media—not the MCP Server Registry and not evidence that any server is listed in it. A single GET request can return a PNG, JPEG, WebP, or PDF. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

Example cURL request:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo documentation for setup and request options. It accepts cookie and consent banners before capture and removes more than 60 known consent platforms, along with newsletter popups and chat widgets; each of those steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up free for 1,000 screenshots a month, with no card required.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.