Rights and contracts
Model context protocol registry: should you list a data MCP server?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
The model context protocol registry is the official public catalog of MCP server metadata: names, versions, packages and endpoints. Listing a data MCP server makes it discoverable, but it grants no data rights; access still runs through the server's own authorization, and any use of the records by an AI company needs a separate signed license. Most servers over company records belong in a private registry or none.
Key takeaways
- The official MCP Registry stores public metadata about MCP servers, not the servers, code or data, and it is still in preview.
- Registry metadata is dedicated to the public domain under CC0, is immutable per version, and deleting a server hides it without erasing its history.
- A listing is discovery, an MCP connection is live access, and a data license is a contract; none implies the others.
- Servers over company records usually belong in a private registry, because the official registry does not support private servers.
- Buyers verify namespace, endpoint ownership, authorization scope and the rights chain themselves, since the registry moderates very little.
What is the model context protocol registry?#
The model context protocol registry is the official public catalog of MCP servers, run at registry.modelcontextprotocol.io. It stores metadata about publicly accessible servers: a unique name, where to find the package or remote URL, how to run or connect to it, and a short description. It does not host the servers, the code or any data they return.
The official project describes itself as being in preview, so breaking changes or data resets may still happen before general availability. It is meant to be read mainly by downstream aggregators such as MCP marketplaces, which copy its metadata, add their own curation and serve it to host applications. Host applications are not expected to read the official registry directly.
The word registry is used loosely, so it helps to separate the layers before deciding anything about a data server.
| Term | What it is | Who runs it | What it means for a data holder |
|---|---|---|---|
| Official MCP Registry | The public metadata service at registry.modelcontextprotocol.io | The registry maintainers, as a community-supported project | Anything listed is public and discoverable by anyone |
| MCP Registry API | An OpenAPI interface other registries can implement | Anyone who builds a compatible registry | A private catalog can look the same to host apps without being public |
| Subregistry or aggregator | A downstream marketplace that copies official metadata and adds ratings, scans or curation | Third parties | Your listing may be copied, enriched and kept by services you never contacted |
| Private registry | A self-hosted catalog for servers only a narrow set of users can reach | Your own IT team or a vendor you choose | The supported route for internal or buyer-only servers |
| Package registry | npm, PyPI, NuGet, crates.io or a container registry that holds the actual code | The package registry operator | The registry entry only points here; code review happens here or downstream |
What does a registry listing actually publish?#
A listing publishes a server.json record, not data. The record names the server, gives a version, points to a public package or a remote URL, and carries a description of at most 100 characters plus optional title, repository and website links.
Three properties matter more to a data holder than to a typical tool developer. First, the metadata you submit is dedicated to the public domain under CC0 1.0, so anyone may copy and reuse it. Second, each version's metadata is immutable once published. Third, removal is soft: setting a server to deleted hides it from default listings, but the historical record stays retrievable, and aggregators may already hold their own copies.
| Listing element | What it contains | Can you change it later? | Data holder note |
|---|---|---|---|
| name | Reverse-DNS name with one slash, such as com.example/claims-history | No, it identifies the server | Use a domain namespace you control so buyers can match it to your company |
| version | A unique version string, semantic versioning recommended | No, publish a new version instead | Decide a version policy before the first publish |
| description and title | Up to 100 characters each describing capabilities | Only by publishing a new version | Describe the tools, never the records or their value |
| packages or remotes | Public package identifiers or a publicly accessible URL | Only by publishing a new version | A remote URL can be claimed by only one server name |
| repository and websiteUrl | Optional links to source code and documentation | Only by publishing a new version | Put scope, permissions and contact details on the website page you control |
| publisher-provided _meta | Custom metadata up to 4 KB under one reserved key | Only by publishing a new version | Anything here is public and CC0 too |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Does listing a data MCP server grant anyone a data license?#
No. A registry listing is discovery metadata, an MCP connection is live access that the server's own authorization controls, and a data license is a signed contract. Each is granted by a different party, and none of them implies the others.
The CC0 dedication in the registry terms covers only the registry data, meaning the metadata you submit, and the terms state it does not extend to the packages a listing points to. It says nothing about the records your server can read.
At runtime, the MCP specification puts consent in the hands of the user and host: hosts must get explicit user consent before exposing user data to servers and must not transmit resource data elsewhere without consent. Authorization itself is optional in the protocol, so a listing should never be read as a statement about what anyone may do with the data. Whether a company may license records depends on four separate permissions, access, privacy permission, ownership and contracts, which our guide to the right to license business records covers in full; the MCP access vs AI data licensing guide and decision tree cover the MCP side.
| Layer | What it covers | Who grants it | What it does not do |
|---|---|---|---|
| Registry listing | That a server exists, its name, version and where to reach it | The publisher, by publishing server.json | Grant access to any record or any right to use data |
| MCP connection | Live reads and tool calls during a user's session | The server's authorization, often OAuth 2.1 for HTTP servers | Grant export, retention, training or resale rights |
| Data license | Defined use of a defined dataset for a defined term | The data holder, in a signed agreement | Depend on whether a server is listed anywhere |
| Privacy permission | Whether personal data may be used for a purpose | Law, notices and consents, reviewed by counsel | Follow automatically from access or a license |
Should a data MCP server go in the public registry, a private registry or nowhere?#
Most servers that reach a company's own records belong in a private registry or no registry at all. The official registry only accepts servers whose package is publicly installable or whose remote endpoint is publicly accessible, and it explicitly points private servers to a self-hosted private registry.
A public listing makes sense when the server is a product you intend anyone to install, for example a documented API wrapper customers already pay for. It rarely makes sense for a server built to answer a single buyer's due diligence, because the listing is permanent public metadata about a deal that may not happen.
| Situation | Usual fit | Why |
|---|---|---|
| Internal assistant reading your CRM or ERP for employees | Private registry or none | The official registry does not support servers limited to a narrow set of users |
| Public product API that customers already access under contract | Official registry, plus your own docs page | Discovery helps adoption; access still runs through your existing customer authorization |
| Evaluation access for one prospective data buyer | No listing; share configuration directly | A permanent public entry would advertise a confidential evaluation |
| Sample or demo server with synthetic data | Official registry is reasonable | Nothing confidential is exposed and it shows the schema buyers will see |
| Server over records you have not yet cleared for licensing | None until rights review is done | A listing can be read as an offer you cannot yet stand behind |
What belongs in a data MCP server listing? A registry listing checklist#
Use this checklist before running the publish command. Because version metadata cannot be edited, every row has to be right the first time for that version.
| Item | What to include | What to avoid | Why a buyer cares |
|---|---|---|---|
| Namespace | A domain namespace verified by DNS or HTTP, matching your company domain | A personal GitHub namespace for a company server | Shows the listing belongs to the company that holds the records |
| Title and description | Capabilities in plain terms, under 100 characters | Record counts, customer names, dataset value or the word license | Buyers read the description as a representation |
| Version policy | Semantic versions, aligned with package or API version, prerelease suffix for metadata-only updates | Date strings that sort unpredictably or reused numbers | Lets a buyer tie a test result to a specific build |
| Remote URL | An endpoint on your own domain, behind authorization | Shared tenant URLs or an endpoint that answers without sign-in | The registry does not check URL ownership, so buyers will |
| Scope and permission disclosure | A website page listing tools, read or write mode, auth method and data categories touched | Vague claims such as full access to company data | Scope is the first thing a security or legal reviewer asks for |
| Owner and contact | A role-based contact and an accountable owner on the linked page | An individual's personal email in the CC0 metadata | Buyers need someone who can answer rights questions |
| Repository link | Source code or a security summary if the server is open source | A private repository link that fails for outsiders | The schema recommends it for transparency and security inspection |
| Rights statement | A sentence on your page that listing and access do not license any data | Silence, which leaves the question to the buyer's assumptions | Prevents a later dispute about what a connection allowed |
| Deprecation plan | Who sets deprecated or deleted status and when | Leaving abandoned versions active | Stale active versions look like an unmaintained data source |
What must never appear in a registry listing?#
Treat everything in server.json as a public, permanent, copyable record. Keep these out of it and out of the publisher-provided metadata:
- Live data or sample records, even de-identified ones; the listing is metadata, and samples belong in a controlled evaluation.
- Credentials, tokens, API keys or default header values; declare a header as a secret input instead of filling it in.
- Internal hostnames, tenant identifiers or network details beyond the public endpoint.
- Language implying a license, exclusivity or availability for AI training, such as training-ready or licensed dataset.
- Customer, patient, employee or counterparty names, or any personal data in the description.
- Claims of affiliation with or endorsement by the official registry or another company, which the registry terms prohibit.
- Prices, record volumes or valuation hints that a buyer could later treat as an offer.
How do you publish a server to the official MCP registry?#
Publishing is a short command-line flow with the official mcp-publisher tool, and each step is a point where a data holder should pause for review. A remote-only server, the common shape for a data service, skips the package steps and publishes metadata pointing at its public endpoint.
- Add ownership verification to the package, if there is one: mcpName in package.json for npm, or an mcp-name marker in the README for PyPI and NuGet. Remote-only servers skip this.
- Create server.json with mcp-publisher init, then replace the generated packages entry with a remotes entry for a remote-only server.
- Authenticate with mcp-publisher login: GitHub for an io.github namespace, or DNS or HTTP verification for your company domain namespace.
- Before publishing, have the people who own the underlying records read the title, description and linked page, because that version's text cannot be edited afterward.
- Run mcp-publisher publish, which sends the metadata to registry.modelcontextprotocol.io under a new, unique version.
- Confirm the entry through the registry API search, then record who on your team owns future versions and status changes.
What will a buyer vet first when they find your server in a registry?#
A serious buyer treats a registry entry as a lead, not as evidence. The official registry moderates very little and keeps low-quality or vulnerable servers listed, so diligence happens on the buyer's side.
| Check | What the buyer looks for | Where the evidence lives |
|---|---|---|
| Namespace match | Does the server name map to the data holder's verified domain? | The registry entry and your DNS or well-known file |
| Endpoint ownership | Is the remote URL on the same domain as the namespace? | The remotes field; the registry itself does not verify it |
| Status and history | Active, deprecated or deleted, and how often versions change | Registry API metadata such as status and publish dates |
| Authorization model | OAuth or another method, scopes requested, read-only or read-write | Your documentation page and the server's auth flow |
| Data categories | Which systems and record types the tools touch, and whether personal data is involved | Your scope disclosure, then an evaluation call |
| Rights chain | Whether the company may license the records at all, separate from serving them | Contracts, privacy notices and a rights review, never the listing |
Does a registry listing help or hurt a data licensing deal?#
A listing helps only indirectly. It can make a company look technically organized and give an evaluator a clean way to test a schema, but AI developers licensing training or evaluation data usually need a prepared historical copy under contract, not a live endpoint. Discovery in a tool catalog is not how those deals start.
A listing can hurt when it blurs the line between access and rights. A public description that hints at valuable records invites inbound requests the company has not approved, can complicate confidentiality during a negotiation, and cannot be reliably withdrawn because history is preserved and aggregators keep copies. If a deal later grants exclusivity, an old listing that suggested open availability creates questions a buyer's counsel will raise.
The safe default for a data holder is simple: list tools publicly only when they are products, keep data servers private, and handle licensing as its own reviewed decision.
How does this apply when you license records through SourceX?#
SourceX is the enterprise data transaction layer for AI: it runs sourcing and qualification, rights review, contracting, data preparation, delivery and payment for businesses licensing operational data to AI developers. That work sits after the access question, not inside a registry.
The company approves exactly what is released, once per deal, and sees what would leave before anything is shared. Large deliveries stay in the seller's own storage or ship on encrypted drives. The first step is a short company assessment, and no data uploads are needed to see if a company qualifies.
Frequently asked questions
Is the MCP registry the same as an MCP marketplace?
No. The official MCP Registry is an unopinionated metadata catalog meant mainly for downstream aggregators. Marketplaces and subregistries copy that metadata and add their own curation, ratings or security scans, and host applications usually read from them rather than from the official registry.
Can I publish a private or internal MCP server to the official registry?
No. The official registry only accepts servers whose package is publicly installable or whose remote endpoint is publicly accessible. Its documentation recommends hosting your own private registry for servers limited to a narrow set of users.
Can I remove a registry listing after publishing it?
Partly. You can set a version or all versions to deprecated or deleted, which hides the server from default listings, but the official FAQ says the deleted status preserves the historical record. The moderation policy allows erasing metadata only in extreme cases, such as unlawful content. Aggregators may also keep their own copies, so assume a listing is permanent.
Does listing my MCP server let AI companies train on my data?
No. The registry stores metadata, and the CC0 dedication in its terms covers only that metadata, not the packages or the records a server can reach. Any use of your records for training or evaluation needs a separate, signed data license and a rights review.
Who verifies that a registry listing is legitimate?
The official registry verifies that the publisher controls the namespace, through GitHub, DNS or an HTTP well-known file, and that referenced packages carry matching ownership markers. It does not verify that you control a remote URL and assumes minimal moderation, so buyers do their own checks.
Sources
- The official MCP Registry is a centralized metadata repository for publicly accessible MCP servers, does not support private servers, recommends a self-hosted private registry for those, and is in preview with possible breaking changes or data resets. Source
- Published version metadata is immutable, a deleted status hides a server from default listings while preserving the historical record, and publisher-provided custom metadata is limited to 4 KB. Source
- Metadata submitted to the official registry is dedicated to the public domain under CC0 1.0, the dedication covers registry data only and not the packages it points to, the registry carries no warranties, and listings must not falsely imply affiliation or endorsement. Source
- The official registry makes no promise about moderation, consumers should assume minimal-to-no moderation, it does not remove low-quality servers or servers with security vulnerabilities, and removal sets status to deleted with metadata still accessible (erased only in extreme cases). Source
- A remote server must be publicly accessible at its URL, the registry verifies the namespace but not control of the remote URL, each remote URL can belong to only one server name, and Streamable HTTP is the recommended transport. Source
- Publishing requires authentication; GitHub sign-in grants an io.github namespace (organization namespaces require an organization Owner) and DNS or HTTP verification grants a reverse-DNS domain namespace. Source
- Every publication needs a unique version string that cannot be changed after publishing; semantic versioning is recommended and version ranges are prohibited. Source
- The registry offers an unauthenticated read-only REST API that aggregators copy on a regular but infrequent schedule, with no uptime or data durability promises, and subregistries can add their own metadata such as ratings and security scan results. Source
- In server.json, the description is limited to 100 characters, the name is reverse-DNS with one slash, and title, repository and websiteUrl are optional fields. Source
- The official registry verifies namespace and package ownership, accepts packages only from listed public registries, and keeps only the publisher-provided key inside _meta. Source
- Publishing uses the mcp-publisher CLI: create server.json with mcp-publisher init, authenticate with mcp-publisher login, publish with mcp-publisher publish, then confirm through the registry API; remote-only servers can skip the package steps. Source
- The registry verifies npm package ownership through an mcpName property in package.json and PyPI or NuGet ownership through an mcp-name marker in the package README. Source
- The MCP specification says hosts must obtain explicit user consent before exposing user data to servers and must not transmit resource data elsewhere without user consent. Source
- Authorization is optional in MCP; HTTP-based implementations that support it follow OAuth 2.1 roles, while STDIO implementations retrieve credentials from the environment. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.