Include mechanism for tagging servers as "archived"

For example, all the servers here: https://github.com/modelcontextprotocol/servers-archived

At some point, they would have been published to the registry as stable servers. Now, they need to be sunset in some way.

We'll probably want this concept baked into the top level server.json because this concept of "archived" is probably useful across server.json use cases.

This was one of the things we were about to bring up so happy to see that issue 😃

Related to this is should this also be available for setting on per package/remote entry too? For example, the whole server might not be archived/deprecated but one of the ways it was packaged so far might have been. Is this a valid usecase or that is expected to be handled by just not including this package anymore in the new version bump?

@rdimitrov

@rdimitrov it's a good question - my gut is that your latter take is the right one:

that is expected to be handled by just not including this package anymore in the new version bump?

It seems unnecessary to introduce the complexity of keeping an archived state per-package. It's necessary at the top server level because deleting at the server level would erase history - vs. we at the lower level we have the more elegant option to publish a new version without the archived package without losing any data. Let me know if you have a use case where that doesn't bear out elegantly.

Yeah, I think the same 👍

The use cases that I can think of for having it are:

This would allow a vendor to mark something as deprecated in order to notify people in advance before removing it completely.
Should we support registry clients having reproducible environments? For example, if I set up an MCP server two months ago, could I recreate that setup today even if its package, remote, or the server itself was deprecated? Probably not as supporting this would increase memory usage significantly and deprecated servers were likely removed for good reasons.

That said maybe it's even worth considering to have something like a garbage collection that cleans all deprecated servers older than X time to keep the registry as fresh as possible.

Fair thoughts, though in the spirit of keeping it simple and not building ahead of need here, I think:

This would allow a vendor to mark something as deprecated in order to notify people in advance before removing it completely.

The consumer could address this by just sticking to an older server version after the new version removes the old package

Should we support registry clients having reproducible environments? For example, if I set up an MCP server two months ago, could I recreate that setup today even if its package, remote, or the server itself was deprecated? Probably not as supporting this would increase memory usage significantly and deprecated servers were likely removed for good reasons.

Well, I do think we are de facto supporting this by hosting not-latest server.json versions. I think that's a nice feature (and provides a working approach to the above problem) and we're already designing for it. Unless you tell me otherwise I don't think it's worth revisiting removing it

That said maybe it's even worth considering to have something like a garbage collection that cleans all deprecated servers older than X time to keep the registry as fresh as possible.

Can talk about if you feel strongly, but my gut is that "fresh" is not a quality we are pitching, and is also a fairly subjective "curation" question I'd rather avoid engaging

The consumer could address this by just sticking to an older server version after the new version removes the old package

+1 👍

Well, I do think we are de facto supporting this by hosting not-latest server.json versions.

Oh, so it will be possible to get a server json for a specific version? Nice, I must have missed that this is already planned/supported thus the reason for my thoughts above (apologies, I'm trying to get to know the project better). I'm definitely not against it, rather the opposite. I support being able to have reproducible environments, but because of the potential memory footprint I thought it might not be of top-priority for the MVP.

Can talk about if you feel strongly, but my gut is that "fresh" is not a quality we are pitching, and is also a fairly subjective "curation" question I'd rather avoid engaging

I think that's fair 👍 Also we can always revisit in case it gets raised by consumers in the future

@rdimitrov

Per @rdimitrov's writing in #200 - I wonder if the change here is not so much "archived or not" and rather some sort of "status" where one of the options is "archived". At the very least we should probably design this field that way so extending it is easier later.

Good point 👍 Do you have any other values in mind? I was imagining Active and Deprecated/Archived but this made me think of things like Experimental for example.

Nothing sticks out at the moment; gut is to start with just Active and Deprecated (I like that more than Archived, thanks) for now. Would be good to see how the field gets used out in the wild before we slice it up more.

Sounds like a plan 😃 If it's alright I'll be happy to help add that property

Add a status field indicating if a server is deprecated or active (#210)

Navigation Menu

Repository navigation

Include mechanism for tagging servers as "archived" #181

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Include mechanism for tagging servers as "archived" #181

Description

Activity

rdimitrov commented on Jul 22, 2025

tadasant commented on Jul 22, 2025

rdimitrov commented on Jul 23, 2025

tadasant commented on Jul 24, 2025

rdimitrov commented on Jul 24, 2025

tadasant commented on Jul 26, 2025

rdimitrov commented on Jul 29, 2025

tadasant commented on Jul 29, 2025

rdimitrov commented on Jul 29, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions