What It Is
A prefix reservation associates a package ID prefix with a verified registry account. Once reserved:- Only the owning account (and accounts they delegate to) may push packages whose IDs start with the prefix
- Packages from the owning account display a verified badge on search cards and detail pages
- Packages from unverified accounts whose IDs start with the prefix are quarantined (push is accepted but package is held pending review)
Prefix Syntax Rules
A valid prefix must:- End in
-or.(the terminating separator) - Be at least 3 characters long (including the separator)
- Match the package ID character set:
[a-z][a-z0-9\-\.]*followed by-or. - Not be a prefix of an already-reserved prefix owned by another account (no nesting conflicts)
| Prefix | Packages it covers |
|---|---|
acme- | acme-tools, acme-git-helpers, acme-mcp |
acme. | acme.core, acme.tools.git |
openai- | openai-tools, openai-plugins |
| Prefix | Reason |
|---|---|
ac- | Too short (less than 3 chars before separator) |
acme | Does not end in - or . |
ACME- | Uppercase not permitted |
How to Claim a Prefix
Submit a request
Fill out the prefix reservation form in the registry UI at
/account/prefix-reservations/new. Provide:- The desired prefix
- Your GitHub organization or user handle
- A brief justification (e.g., “We maintain the official Acme MCP integrations”)
Manual review
The registry team reviews the request. Approval criteria:
- The prefix clearly maps to the requester’s published identity or project
- The requester already owns (or intends to publish) packages under the prefix
- No existing packages from other accounts would be retroactively quarantined
Verified Badge
Packages from verified prefix owners display a shield badge (✓) on:- Search result cards
- Package detail page headers
- The
verified: truefield in search API responses
What Reservation Does NOT Do
Prefix reservations provide registry-level ownership, not legal protection:- No trademark protection — A reservation does not grant intellectual property rights. Trademark disputes are handled outside the registry.
- No domain verification — Claiming
acme-does not verify that you ownacme.com. - No retroactive cleanup — Packages from other accounts that predate the reservation are not deleted. They are quarantined only if a new push arrives after the reservation is active.
- No subdomain enforcement — Reserving
acme-does not covermy-acme-tool(the prefix must appear at the start of the ID).
Transfer and Release Policy
Transfer
Transferring a prefix reservation to another account requires registry team involvement. Both the current owner and the receiving account must confirm the transfer via email.Voluntary Release
An owner may release a reservation voluntarily by submitting a request via the registry UI. Released prefixes become available for anyone to claim after a 30-day cooling period.Revocation
The registry team may revoke a reservation for:- Abuse — using the prefix to impersonate another project or distribute malicious packages
- 24-month inactivity — no packages published under the prefix for 24 consecutive months, with no response to a warning email within 30 days
Registry API
There is no public endpoint for prefix reservation management at MVP. Theverified boolean in search results and registration blobs is set server-side and is not directly queryable.
GET /v3/prefixes/{prefix} to query reservation status.