Repository navigation
Community-driven mechanism for takedown of spam/malicious servers #92
Description
Some discussion here: #93
When someone publishes a malicious or spam server.json, we need a mechanism for getting it reported and taken down.
While we can rely on existing source registries that we reference (e.g. npm, pypi, etc) to pull down malicious source code, we can't rely on the same mechanism for remote servers.
Steps to do here:
- Evaluate how other registries in the ecosystem deal with this. Likely solution is to enable community reporting of spam/malicious intent.
- Design mechanism for making those submissions
- Set thresholds for what meets the bar for a takedown
- Implement
Reacted by Jerric Lyns John
Activity
steiza commentedon Jun 6, 2025
Usually this is handled by having the humans that operate the registry monitoring some sort of inbox / report queue for people reporting a submission as malicious. If the registry has a web interface, you can implement sending a malicious report from the page associated with the submission.
See things like:
tadasant commentedon Jun 9, 2025
We weren't planning on having a web UI at initial launch, but I wonder if we could facilitate something similar with a PR process + label on modelcontextprotocol/registry.
pavinduLakshan commentedon Jun 13, 2025
As an immediate solution, we could start by verifying the existence and reputation of the domains of the submitted remote mcp servers, checking the domain presence in search engines, and validating the identities of those submitting MCP servers to the registry. Once an MCP server is added, these details will also be available in the registry API responses as well. While this approach isn't foolproof and could potentially be manipulated (with a considerable effort), I believe this provides a reasonable starting point for going live.
tadasant commentedon Jun 13, 2025
Let's focus this issue specifically on takedown mechanisms after proactive measures have failed us^. What you're describing sounds like a suggestion for how to further enrich our reverse-DNS namespacing mechanism, which is a separate topic.
jonathanhefner commentedon Jun 13, 2025
One concern here is brigading. Should a server with 100k downloads be taken down due to 100 reports? Would there be an appeal process?
Perhaps we could track report counts alongside download counts, and leave the decision and appeal process to aggregators.
We could also consider aggregating stats over sliding windows, e.g. "reports in the last week", "reports in the last month", "reports in the last 6 months".
tadasant commentedon Jun 25, 2025
Good callout on brigading. Maybe we allow for reporting a whole server, and reporting a specific version; with the option to permanently whitelist something (i.e. prevent future reporting on it) by appeal.
So if someone gets brigaded, they can appeal, and then be permanently shielded from brigading thereafter after manual review.
Distinguishing between version and server whitelisting could be important: servers are more likely to be reported as spam; versions are likely to be reported as malicious (e.g. supply chain attack). Permanent whitelisting of a server doesn't mean all its versions should be un-reportable.
domdomegg commentedon Aug 22, 2025
As per #150 (comment), for go-live we will do manual moderation and see how it goes. Going to track:
rdimitrov commentedon Apr 24, 2026
Closing this out as substantively complete. What shipped:
PUT /v0/servers/{id}withServerStatusDeleted(anti-undelete protected), via feat: add admin edit endpoint for server moderation #315All four of the original checkboxes are covered. If a dedicated reporting form (distinct from GitHub issues) becomes useful later, that'd be a fresh, smaller-scope issue.