Repository navigation
Automatically remove server.json entries referencing invalid packages #93
Description
Some discussion here: #50
In the case where npm, pypi, etc. take down a package (e.g. in the case it is found to be malicious), we don't want to maintain a reference to that package.
Because server.json is meant to be immutable, what we should probably do in this case is delete the version of the server.json altogether.
We'll want to run this kind of check (for broken package references) at least ~daily.
Activity
domdomegg commentedon Aug 21, 2025
Other related problem this solves: avoid user disappointment due to them finding an interesting MCP, trying to install it, and then finding the underlying package has been deleted so it doesn't work.
domdomegg commentedon Aug 21, 2025
Related - could probably test this implementation on (and clean up) our seed data: #49
domdomegg commentedon Sep 1, 2025
Analysis generated by Claude Code to help evaluate the implementation approach and priority.
Analysis of Automated Package Validation Requirements
I've done a technical analysis of implementing automated package validation for detecting and removing server entries with invalid package references. Here are my findings:
Technical Feasibility ✅
The implementation is definitely feasible. I've identified several viable approaches:
last_validated_attimestampsAll approaches would involve HTTP requests to package registries (npm, PyPI, etc.) to verify package existence and remove invalid server entries from the database.
Priority Assessment 🤔
However, I want to raise some questions about necessity and timing:
Low actual impact scenarios:
Implementation overhead:
Alternative Recommendation 💡
Consider a phased approach:
Phase 1 (Minimal viable solution):
Phase 2 (If needed based on real data):
Questions for the Team 🤷
I'm happy to implement whichever approach the team decides on, but wanted to surface these considerations for discussion.
tldr: If we want to implement it, I think an ongoing background job is probably the way. But it does add a lot of development complexity especially with the number of registries and handling things like rate limiting, retries etc. for deletions which should be fairly rare (and clients won't actually be able to download malicious packages after they have been removed from source registries). So maybe for now we should consider this not a go-live blocker?
tadasant commentedon Sep 1, 2025
I would caveat this with: if someone published a malicious package to both
npmand an oci build of it todockerhuband also an MCPB bundle, andnpm's detection mechanisms took it down, we'd do well to just follow npm's lead and take it down across all its package formats.That said, agree this is something of an edge case and think we can remove it from go live blockers.
rdimitrov commentedon Oct 23, 2026
Consolidating periodic package revalidation into #1715, which now holds the implementation discussion across package/repository drift and remote endpoint checks. I explicitly preserved this issue's daily-check suggestion and cross-distribution malicious-package revocation concern there. This closure does not mean checks or removals have been implemented, and security revocation must be distinguished from ordinary transient validation failure.