modelcontextprotocol
Enforce some daily publish limits
We originally planned to rate limit authenticated users to one new server per user/org per day.
@SecretiveShell flagged: "please hold off on this for the initial week, as I and probably many other people would want to add their multiple existing servers in one go when it initially launches"
This makes sense to me. If we do enforce that rate limit, we'll want some initial grace period at least. But it may be worth reconsidering the rate limit pace altogether (maybe there will be plenty of use cases where e.g. an enterprise adopts MCP and wants to launch dozens of servers on one day?).
So I think:
- When we initially go-live, start with a looser limit, like 10 servers per use per day; make sure we have the data to retroactively analyze usage patterns on this front (e.g. timestamps of every publish action)
- After it had been live for a few weeks, analyze the data
- Adjust rate limits based on the data we're seeing
- Provide an escape hatch: allow folks to open a PR requesting a rate limit exception (e.g. a YAML file with rate limit exceptions)
I'd be pretty fine not having this for launch - as long as we have some basic moderation tools that allow us to e.g. 'delete all packages by this uploader'. Or perhaps having very high limits (e.g. 1000 packages per day).
I think in practice people are unlikely to abuse this, and the severity of impact is fairly low - compared to how annoying a limit of 1 or 10 servers might be for the power users of MCP (who are crucial to the ecosystem!). I say this as someone who seems ~reasonably likely to exceed 10 servers per day occasionally.
I don't want to rely too heavily on moderation here long term - would agree with low limits if this does turn out to be a problem. Just that I'd lean towards this probably not being a problem by default.
(Also if this is a widespread problem, I think another issue will be people creating many accounts and spreading quota across them - that will make things more difficult... I wonder if a Claude-powered screening would be useful here for spam packages).
Fair, I don't feel strongly on this. We did receive consistent advice from some major registry maintainers (npmjs, packagist) that spam of various kinds will be a problem at some point ("people will spam any popular system they can find on the internet"), so I wouldn't bank on it not being abused, but I agree that having a hard limit here could be problematic for power users.
I don't mind punting this to post-go-live if we do have reasonable moderation mechanisms in place as you said.
Agree re: Claude-powered screening as well, and maybe that subsumes this need if done well - https://github.com/modelcontextprotocol/registry/issues/101