Allow publishers to mark servers as deprecated

See: https://discord.com/channels/1358869848138059966/1369487942862504016/1425290448548921436

We should offer a CLI-based mechanism for authenticated publishers to mark an entire server (i.e. all versions of a name) as deprecated status.

We should also include clear guidance for sub-registry implementors that this functionality exists and they should be reading the data accordingly. Maybe we start a guidebook on sub-registry implementor guidance?

@tadasant

@tadasant Can I take this up, if that works ?

@pree-dew

Thank you @pree-dew! I think yes, but let's get a thumbs up from either @domdomegg or @rdimitrov to make sure I didn't miss anything regarding the requirements here

@pree-dew

@pree-dew - you're more than welcome! 🚀

Some of the items I have are:

Should we have this on per version or per server basis? My take is per server but should we consider cases where users want to mark a particular version?
Should authors be able to change the state from deprecated back to active?

Other items (probably not part of this issue but related to supporting status changes):

I think I'm revisiting this but should authors be allowed to set the status to deleted?
Querying for servers should include all states (active, but also deleted and deprecated), right? Necessary so sub-registries can reflect that. This is related to the discussion we had on the MCP Summit what would the return value be? Is it the whole metadata or just name + status for anything else != active?

Hmm should we differentiate between yanked and deprecated? Maybe versions can be yanked and servers can be deprecated? Maybe yanked==deleted.

I don't know offhand the right modeling/naming for this. We should explore how at least a few other registries do this and then align with a model that we like before implement here.

If yanked==deleted, then I think for now we wouldn't allow server publishers to yank/delete. We'd only allow them to deprecate an entire server.

@tadasant

@tadasant I will explore some other registries to have better idea about this before implementing. Although I think to start with deprecating an entire server is a good starting point, it might be the case that we may get better idea about how to handle the other scenarios of deleted or deprecating per version as per the use cases that will come from users.

Hello,

Did you advance on this issue by any chance? While deleting servers or packages might not be common for static package managers, I feel like it's a feature that makes a lot of sense for remote MCP servers:

if the server is not available at the publicized URL, you don't want to keep it in the registry linking to a 404.
if you buy a domain name that previously had a MCP server published that has nothing to do with yours, you don't want it to show in the history of your MCP server versions?

@rodincave

@rodincave Due to priority of other issue of logs, I thought this might be picked up later. But I can pick this up now as the other task is done. Thank you for highlighting this.

@pree-dew

One more proposal to throw into the mix:

On the server-version level, add a nextName and prevName field
This allows for the /v0.1/servers/{serverName}/versions endpoint to string together a full list when returning for any name in a chain
It's at the server-version and not server level so you can in theory do a rename and then rename again back to the original
We should probably limit the number of renames to something like 5-10 so as to limit the amount of ugly DB queries we'd need to do to string these together on the /v0.1/servers/{serverName}/versions endpoint
We do need to be careful with malicious or ambiguous nextName/prevName entries; but I think it's sufficient to basically only allow setting them if you have validated both DNS prefixes + you have no conflict (e.g. conflicting nextName) with another entry

Haven't thought through whether I think this the best proposal though vs. some other deprecated/yanked scheme. Maybe nextName/prevName is useful to have in addition to a deprecated/yanked status for constructing the links to "what's next"?

@pree-dew we've been getting a lot of demand for this feature so I think it should be pretty high on the priority list, do you have a sense when you'll be able to make some progress on it?

Thoughts for status at the root level:

active: findable and searchable [default]
archived: "soft" deletes so the entry exists, does not show up for search queries.

These at the version:

yanked: with a required message non-empty string 'superseded by ...' or 'vulnerability ...'

Claimed owners should be able to update status.
Disputes, malicious, errors, and abandoned entries are out of scope

Also, for authentication tokens should work (without TXT, or .well-known)

@tadasant

@tadasant Noted, I will be able to pick this up in this week itself and will try to wrap up asap.

Few questions that are added in implementation document, adding here again for reference

Questions:

Do we need bulk endpoint for status transitions, renaming?
Do we want to allow publisher to make status transition?
Do we want yanked package discoverable?

Link to PR
#893

Do we need bulk endpoint for status transitions, renaming?

No, we do not need, but it would be nice to have one.

Do we want to allow publisher to make status transition?

Yes, who would be responsible without administrative help?

Do we want yanked package discoverable?

Yes, but only if their status is clearly identified. There are cases where the reason of yanking has been helpful.

Publisher-managed "deleted" support (modelcontextprotocol#893)

Navigation Menu

Repository navigation

Allow publishers to mark servers as deprecated #637

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow publishers to mark servers as deprecated #637

Description

Activity

pree-dew commented on Oct 8, 2025

tadasant commented on Oct 9, 2025

rdimitrov commented on Oct 9, 2025

tadasant commented on Oct 10, 2025

pree-dew commented on Oct 14, 2025

rodincave commented on Dec 1, 2025

pree-dew commented on Dec 2, 2025

tadasant commented on Dec 31, 2025

scottschreckengaust commented on Jan 1, 2026

scottschreckengaust commented on Jan 1, 2026

pree-dew commented on Jan 5, 2026

pree-dew commented on Jan 16, 2026

pree-dew commented on Jan 16, 2026

scottschreckengaust commented on Jan 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions