What MCP Registry is and where it fits
MCP Registry is the official metadata directory for Model Context Protocol servers, not a hosted tool runtime or a polished end-user marketplace. Publishers submit a standardized server.json record that names a server, its version, repository, installable packages, or remote endpoints; clients and downstream aggregators read that record through an open HTTP API. This neutral role is the product's main advantage. It gives ecosystem builders one standards-aligned source of install and connection metadata instead of forcing every editor, agent platform, and catalog to scrape project websites or maintain a private list.
That narrow scope matters when evaluating fit. The hosted registry accepts publicly accessible packages and remote servers, while private packages or internal-only endpoints belong in a self-hosted registry. The official documentation also calls the service a preview and warns that breaking changes or data resets may occur before general availability. Teams should therefore treat it as a synchronization source with local caching, validation, and fallback behavior, not as an infallible control plane. It is strongest for publishers, MCP client teams, aggregators, and platform engineers; individual users looking for ratings, one-click hosting, or runtime monitoring need another layer.
Hands-on publisher workflow
We tested the official mcp-publisher v1.8.1 binary, built from commit f52dc8525a441a3abf5fedc9912152d95af5aab1. Against the live validation endpoint, a server.json using the current 2025-12-11 schema, a test io.github namespace, version 0.0.1, repository metadata, and a Streamable HTTP remote returned "server.json is valid." A malformed control with an invalid registry name returned HTTP 422 and identified body.name plus the required namespace pattern. That makes the validate command useful in CI: it catches schema and semantic problems without publishing a record or requiring an authentication flow.
For the full path we ran the same v1.8.1 publisher and registry binaries against an isolated local PostgreSQL instance, enabled only the documented anonymous testing method, and used io.modelcontextprotocol.anonymous/aicoolies-review-test. The first publish was rejected with HTTP 422 because description exceeded the current 100-character limit; after shortening only that field, publish succeeded and the v0.1 API returned the exact name, version 0.0.1, repository, remote, active status, and latest-version marker. This was a useful real-world result: the happy path is short, but server.json limits are enforced at publish time and deserve a preflight step.
Ownership and validation boundaries
Namespace ownership is a substantive anti-spam control rather than a naming convention. GitHub OAuth or GitHub OIDC grants an io.github.<user-or-org> namespace; DNS and HTTP challenges support domain-based namespaces. Package ownership is checked separately: npm packages must expose a matching mcpName, OCI images use the io.modelcontextprotocol.server.name annotation, and other package types have their own proof requirements. This two-part model links the publisher identity to the namespace and the referenced artifact to the same server name, reducing casual impersonation and metadata that points at an unrelated package.
Our local negative test confirmed the authorization boundary. The anonymous test token carried publish and edit permission only for io.modelcontextprotocol.anonymous/*. Reusing it to publish io.github.aicoolies-review-test/registry-hands-on returned HTTP 403, reported the permitted resource pattern, and named the attempted namespace; no record was created. The boundary is valuable, but it is not a security review of server behavior. A verified publisher can still ship vulnerable or over-privileged code, and the registry terms explicitly place suitability evaluation on consumers. Client platforms still need package provenance, sandboxing, permission review, and update policy.
Registry API filtering and client integration
The read API is simple but operationally useful. A live v0.1 query combining search=filesystem, version=latest, and limit=5 returned five latest records plus a nextCursor. Repeating the query with mixed-case FiLeSyStEm produced the same names, confirming case-insensitive substring search; sending the returned cursor produced a non-overlapping second page. A separate updated_since=2026-08-01T00:00:00Z query combined with version=latest and include_deleted=true returned recently changed records with active status and timestamps. These filters support catalog refreshes and incremental mirrors without re-downloading the entire registry.
We also exercised the metadata-to-client handoff instead of stopping at JSON inspection. A live search resolved io.github.microsoft/playwright-mcp version 0.0.79 to the npm package @playwright/mcp at the same version with stdio transport. In a secrets-free disposable Node container, a minimal MCP client launched that package, sent initialize and notifications/initialized, then requested tools/list. The session returned 24 tools, including browser_close, browser_resize, browser_console_messages, browser_handle_dialog, browser_evaluate, browser_file_upload, browser_drop, and browser_find. This proves the record can drive a real client launch, while also showing that execution responsibility stays with the client.
Pricing, licensing, and operating cost
The hosted public read API and publisher tooling have no listed subscription or per-seat fee, and the project can be self-hosted. Costs appear in the surrounding system: a private deployment needs PostgreSQL, service hosting, upgrades, monitoring, and a synchronization policy; client teams must also cache metadata and evaluate packages before execution. The registry does not host npm, PyPI, NuGet, OCI, Cargo, or MCPB artifacts, so publishers continue to pay and operate whatever distribution channel their server uses. For most open-source publishers the cash price is effectively free, but production ownership is not zero.
Licensing deserves precise wording. The v1.8.1 release bundle says the MCP project is transitioning from MIT to Apache-2.0: new code and specification contributions use Apache-2.0, contributions without relicensing consent remain under MIT, and non-specification documentation uses CC-BY-4.0. GitHub's repository API therefore reports NOASSERTION rather than a single SPDX license. Organizations redistributing or modifying the code should retain the bundled license text instead of summarizing the whole repository as only MIT or only Apache-2.0. Registry metadata submitted to the hosted service is also intended to be public, so private descriptions or credentials never belong in server.json.
Limitations and verdict
Discovery quality is intentionally basic. The official search parameter is a case-insensitive substring match on server names, and the documentation directs richer ranking or filtering to subregistries. There are no built-in reviews, trust scores, behavioral scans, hosted execution controls, or private-server support in the public service. Preview status adds change risk, and publisher success proves metadata consistency and ownership rather than runtime safety. Teams that need curated recommendations, enterprise policy, secrets brokerage, audit history, or managed deployments should place a catalog or gateway in front of the registry rather than expecting the registry to become that product.
MCP Registry is nevertheless the right default metadata backbone for public MCP discovery. The official namespace model, artifact verification hooks, current publisher CLI, cursor-based API, latest-version and incremental-update filters, and self-host option solve an important interoperability problem with little ceremony. Our tests found clear and actionable failures for schema limits and namespace misuse, then carried a real registry record into a successful client handshake. We recommend it to MCP publishers, client authors, and aggregators that can own validation and caching. End users should consume it through a curated client or platform, not treat every listed server as endorsed.
