Why not use etcd or another open well-established/tested/multiclient discovery system?

[scottslewis]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

It seems to me that a mcp distributed registry could benefit significantly by using an existing, well-established, federated protocols...e.g. etcd.

[abhishekkushwahaa]

Hey, @scottslewis great point!

Honestly, using something like etcd sounds like a pretty smart move. Why reinvent the wheel when there are battle-tested solutions out there doing exactly what we need? etcd gives us strong consistency, built-in leader election, and all that Raft magic—basically, the secret sauce for a reliable distributed registry.

That said, we should also make sure we’re not inviting extra complexity just for the fun of it. Running etcd clusters isn’t exactly a “set it and forget it” job… unless we want to live on the edge and deal with split-brain scenarios at midnight. 😅

But seriously, if we can avoid building a custom registry from scratch and get the stability of a tried-and-true system, I’m all in. Let’s just double-check that it plays nice with our scaling goals and doesn’t turn into an operational headache.

Happy to nerd out more about this if needed!

[scottslewis]

Hey, @scottslewis great point!

> > That said, we should also make sure we’re not inviting extra complexity just for the fun of it.

Oh...my suggestion isn't for the fun of it. Every network discovery system (e.g. for services) runs into the same set of distributed system problems: multi-servers/federation, distributed consistency, dynamics, scaling, naming, versioning, security, decentralized administration, etc. MCP Registry will as well...if successful.

Running etcd clusters isn’t exactly a “set it and forget it” job… unless we want to live on the edge and deal with split-brain scenarios at midnight. 😅

Sure...distributed admin and federation remain hard. The thing that I like about etcd is that you can run it as a standalone server...e.g. for development/testing/etc...and then move to a clustered environment for deployment/scaling and federation. I do this all the time to test remote services.

Plus it's based upon grpc/protobuf, so there are good quality open source clients in most languages.

But seriously, if we can avoid building a custom registry from scratch and get the stability of a tried-and-true system, I’m all in. Let’s just double-check that it plays nice with our scaling goals and doesn’t turn into an operational headache.

What are your scaling goals? I understand that the project is new and this is probably being figured out so I'm not trying to be difficult. And wrt operational headache...that's sort of dependent upon how/what is being done for this project in terms of deployment/admin/scaling of the first registry...+ future support for third parties/independent registries, etc.

BTW, I"ve been working on MCP dynamic tool groups here, which would/could provide some degree of architectural support for the MCP Registry effort...e.g. to allow some multilanguage hierarchical structure for tools namespaces. One use for such grouping is for metadata (tools descriptions) ownership (e.g. these tool groups associated with these developers, communities, or organizations).

Also, there has been some excellent service meta-data standardization work in OSGi Remote Services over the past 15 years. Specifically, the standardization of EndpointDescription service meta-data. My point in mentioning this is that one way to go about an MCP Server registry would be to create an extensible set of MCP Server 'microservices' (contracts without impls) that could then be exposed for discovery via etcd (or some other discovery protocol). I've been beginning to think about this with the MCPToolGroups work (see the examples.remote projects...which use remote services for the MCP ExampleToolGroup API)...and I'm testing using etcd3 discovery for remote service discovery of these example MCP Servers and available ToolGroups.

And just to (hopefully) alleviate any possible concerns about Java the language nature of RSA specification, some time ago I built support for the RSA spec into Python via Ipopo. This is possible because the EndpointDescription meta-data spec is language independent, along with RSA having full pluggability for remote service discovery protocols...including etcd3.

[tadasant]

When someone has some time, could you please share some examples of problems you think we'll run into given the MCP Registry's scope and design goals? Would be helpful to understand the specific pain points before we dig into discussing adopting solutions and standards.

[scottslewis]

When someone has some time, could you please share some examples of problems you think we'll run into given the MCP Registry's scope and design goals?

I personally have not been privy to the scope and design goals discussions among the MCP Registry team, so I can't comment in detail about that.

I do have some experience with distributed systems, protocols, and communication and so can provides comments based upon that experience.

Registries usually contain meta-data about something that is accessed via the internet...e.g. web servers, microservices, mcp servers, apps, pages, internet hosts, etc. By meta-data I mean stuff like unique names, version info, tags (to aid in searching), descriptions, titles, identity/security/trust info (creator, certs, etc). The relevant kind of meta-data is specific to what is being described and how it's to be used. For example, LLM text descriptions for MCP tools is a kind of meta-data intended for use by models rather than humans (generally).

Building a single registry can be technically challenging, but if there are two or more of such registries connected by a network things quickly become much more difficult. One of the main difficulties is keeping the meta-data in sync/consistent among > 1 servers when the meta-data changes. This can be very challenging to do with a federated (more than 1 server) approach. The consistency (and reliability) complexities increase rapidly with the number of copies of the meta-data.

So...one hard problem: Distributed consistency for meta-data (about mcp servers in this case). Yes there are of course technical solutions (from DNS, to Paxos, to distributed dbs, clustering, sharding, etc). There has to be some protocol between federated registries to keep things in sync. etcd3 is one example impl that has support for maintaining consistency among multiple servers.

Note that there are also degrees of federation...e.g. commercial app stores are (probably) multiple servers...but are run and administrated by a single entity (e.g. the app store 'owner'). The consistency issues are harder for the 'full federated' case...i.e. many other registries run and administered independently. There are also more questions of security (i.e. what's secure for my registry users server vs. yours vs a startup's?).

My point in bringing this up with the new MCP Registry project is just that if the goals of the project are to have a single MCP Server Registry, run by a small group, that's fine. But from the initial reading it appeared to me that perhaps the MCP Registry project was headed toward a more federated/distributed approach to finding/using/downloading? MCP servers, which implied to me that perhaps using some of the good work in distributed systems protocols, consistency and reliability, tested and open source solutions (etcd3 among many others) might be a good way to go.

FWIW, I understand and appreciate a 'start small and/or centralized and expand architecturally from there' approach...especially for open source/community-driven projects. I'm not intending to be critical of that approach. Rather I just was curious where things were with the project and so this discussion.