Repository navigation
Include mechanism for tagging servers as "archived" #181
Description
Activity
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 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
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
ActiveandDeprecated/Archivedbut this made me think of things likeExperimentalfor 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.
Reacted by Radoslav DimitrovSounds like a plan 😃 If it's alright I'll be happy to help add that property
Reacted by Tadas Antanavicius- added a commit that references this issue
on Jul 31, 2025 - added a commit that references this issue
on Aug 7, 2025
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.jsonbecause this concept of "archived" is probably useful acrossserver.jsonuse cases.