Entry Criteria

[ChrisJBurns]

I believe we should have entry criteria to what makes its way onto the registry. I've spoken about this previously but I feel we have the opportunity to not just shift security left, but to start left.

Instead of making it the wild-west of what can make its way onto the registry, we should have some entry criteria that all MCP servers have to meet in order to get represented.

Some of the criteria should include:

• Is the server maintained?
• Is there any attestations that provide information about server signing or build proof?
• Security risk (taking into account CVEs) so that users can see how vulnerable a server is before they pull it

Happy to work with people on this.

[tadasant]

We are very open to progressive improvements that would increase the base level of confidence we can bake into the centralized registry.

A line that I think we should toe: avoid opinionated takes on what is "good enough". Any cutoffs or filters we use should be decidedly vendor-neutral, objective, and not subject to context/interpretation.

To that end, something like Is there any attestations that provide information about server signing or build proof? and Security risk (taking into account CVEs) so that users can see how vulnerable a server is before they pull it could both be very useful.

I am less enthusiastic about Is the server maintained? -- while it's a nice heuristic for an average case, the level of maintenance that a particular kind of MCP server might need varies wildly. So beyond making sure that a consumer can figure out the answer to that question for themselves on a per-server basis (e.g. because there is a source_code_location URL the consumer can fetch to see when the source code was last updated), I don't think we should go so far as to include that kind of data or filter on it in the registry.

[cliffhall]

Is there any attestations that provide information about server signing or build proof?

We've talked in the past about using DNS records to indicate ownership. E.g, a TEXT record using some generated token to prove the controller of the domain is the one registering the server. So some rando couldn't publish an "official" Github server, only someone who manages github.com's DNS could do it.

It occurs to me that we could also put something along the lines of what you see in package-lock.json for npm packages. For instance, if my company publishes its puzzlebox server, which actually exists on my personal repo, that disparity is cleared up because I control the futurescale.com domain.

{
  "version": "0.2.0",
  "server": "puzzlebox",
  "publisher": "futurescale.com",
  "resolved": "https://github.com/cliffhall/puzzlebox/archive/refs/tags/0.2.0.tar.gz",
  "integrity": "sha512-BNGbWLfd0eUPabhkXUVm0j8uuvREyTh5ovRa/dyow/BqAbZJyC+5fU+IzQOzmAKzYqYRAISoRhdQr3eIZ/PXqg=="
}