Decide on production SLA

[toby]

After we go live, we should communicate what our SLA is. We've had discussions around a 24h downtime tolerance, which would mean that no server publication could happen during that timeframe. Ultimately this will depend on how we host and who is responsible for upkeep (volunteers vs. companies with dedicated resources).

[domdomegg]

I'm pretty happy to go with officially having 24h downtime tolerance for go-live, even if in practice we do better than this SLA. Better to set low expectations and exceed them, than the other way around. Plausibly it should actually be something like 1 business day... e.g. if an incident happens at 10pm on a Friday, will we actually get to it on the weekend?

One reason we might not want to do this is that it would prevent people using the registry - how likely do we think this is? From the Anthropic side I don't think this is a concern/blocker for us.

[domdomegg]

Other potentially useful context for thinking about this:

• Anthropic has been exploring how we can transition MCP governance to be fully open-source/community-owned. This might include coming with some funding for things, which could fund a proper maintainer for this. This could in turn result in changes to SLAs around MCP in the near future, so perhaps this decision right now isn't super consequential.
• Looking at peer registries, many of them don't really make specific uptime guarantees that I could find (e.g. NPM, PyPi). NuGet did have availability targets in 2014 though.

[rdimitrov]

Another related note is would there be a security response team, i.e. leverage GHSA or something like security@modelcontextprotocol.io where people can submit issues in private expecting a reply within a certain timeframe? The issues for example can vary from - "hey, I found a way to publish on behalf of someone else" to "This MCP server is malicious, you should remove it" and so forth.

[domdomegg]

@rdimitrov on security that's a good point. My guess is:

• "There is a vulnerability directly in registry, e.g. I can publish as someone else" should go through the standard MCP security policy. Currently this routes to a CSIRT team inbox that is monitored 24/7 by Anthropic security engineers, although I think we will at some point move this over to the MCP community once we build up capacity here - possibly tying in with the move to fully open-source owned.
• "This MCP server is malicious, you should remove it" is lower priority and can be handled by general registry team. We do need to build this process though, and probably have some clear runbook for it. Example from Rust.

[domdomegg]

Recording decision from maintainers meeting today: we are aligned that:

• we have a long SLA, at least 24 hours
• we will advertise registry as a 'preview', not GA
• we will use the main MCP security process (currently Anthropic, soon to be an MCP Hacker1)
• we will set up some very basic abuse reporting system (possibly just 'please shout on Discord' or 'raise a GitHub issue') for go-live, can explore cleverer solutions later. we can remove malicious servers with "Admin" panel for the official registry API #182. we will generally take a permissive approach to what goes on registry and only commit to removing actively illegal content e.g. malware, DMCA violations.

The implementation work tasks now are basically writing that documentation and putting it in this repo.