Decide on production SLA #150

Activity

1. toby

   added

   go-live blockerThis issue is one we need to address prior to initial go-liveThis issue is one we need to address prior to initial go-live

   on Jun 27, 2025
2. domdomegg commented on Aug 19, 2025

   

   domdomegg

   on Aug 19, 2025

   Member

   More actions

   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.

   👍React with 👍2Reacted by Radoslav Dimitrov and Tadas Antanavicius
3. domdomegg commented on Aug 19, 2025

   

   domdomegg

   on Aug 19, 2025

   Member

   More actions

   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.
4. rdimitrov commented on Aug 19, 2025

   

   rdimitrov

   on Aug 19, 2025

   Member

   More actions

   Another related note is would there be a security response team, i.e. leverage GHSA or something like [email protected] 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.
5. domdomegg commented on Aug 19, 2025

   

   domdomegg

   on Aug 19, 2025

   Member

   More actions

   @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.

   👍React with 👍1Reacted by Radoslav Dimitrov
6. domdomegg

   added

   product requirements workUpstream of development workUpstream of development work

   on Aug 20, 2025
7. domdomegg commented on Aug 22, 2025

   

   domdomegg

   on Aug 22, 2025

   Last edited by domdomegg

   Member

   More actions

   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.

   👍React with 👍1Reacted by Radoslav Dimitrov
8. domdomegg

   added

   implementation workShovel-ready to write codeShovel-ready to write code

   and removed

   product requirements workUpstream of development workUpstream of development work

   on Aug 22, 2025
9. domdomegg

   self-assigned this

   on Aug 26, 2025
10. domdomegg

    linked a pull request that will close this issueUpdate documentation structure and content #302on Aug 26, 2025
11. domdomegg

    closed this as completedin #302on Aug 26, 2025