Add docs: design principles, FAQ, roadmap, architecture

[tadasant]

Adding more up-to-date documentation to address #131:

We are starting to get a lot of repeat questions that we have answers to scattered throughout docs and issues. The designs in the #11 are starting to grow stale, so we should have a better running document somewhere in version control.

This PR adds:

• design_principles.md - Core constraints and principles guiding the registry design
• faq.md - Frequently asked questions about the MCP Registry
• roadmap.md - High-level roadmap for the MCP Registry development
• architecture.md - Technical architecture, deployment strategies, and data flows

[connor4312]

Is this actually the case? I could easily publish an npm package containing a closed-source binary.

[tadasant]

Good point, you're right, we don't have a reasonable means to enforce that. Will rephrase such that open source is encouraged but not required.

[jonathanhefner]

This looks great! Very helpful to someone who hasn't closely followed all of the discussions. 😅

[jonathanhefner]

Pursuant to #134 (comment), you might want to omit "open source" here as well.

[toby]

I think it's good to encourage caching of data but I'm hoping we can have a better SLA than 24 hours of downtime since publishers won't be able to publish new servers during that time.

[tadasant]

My biggest concern about sub-24h is that anything under 24h necessitates on on-call schedule. If we frame it as 24h, then we can rely on volunteers coming online once a day.

I know it's not great for productivity if publication is offline for 24h, but maybe we start with a 24h SLA and once we get a sense for adoption + other maintenance needs, we could then seek to create a permanent operational position that is funded/sponsored by someone?

[toby]

We'll probably want a bit higher of a limit. I could imagine a company publishing at least a few servers in day.

[tadasant]

Fair, if we make it 10/day that probably does enough to still discourage mass spam and likely won't severely impact a company trying to launch a set of servers.

[tadasant]

Noted here #21 too

[toby]

I like that and the "escape hatch", it should protect against spam but still give us a way to support enterprises that want to go all-in on MCP.

[tadasant]

Thanks for the feedback everyone! I'm about to head out for a week of OOO, so will be circling back to address when I'm back.

[patrick-rodgers]

No interest in blocking anyone from building and publishing a server - but say we released an in-service MCP server for OneDrive, how would that be differentiated from the 100 other implementation that have OneDrive in the name/description/access OD files? Substitute OneDrive for GDrive or any other service. This is the app store problem of a bunch of very similar things being very confusing for users.

Say I am a consumer, I know nothing of tech, and I search for "OneDrive" in MCP registry and get 100 results - how would I make a choice?

[jonathanhefner]

I think that amounts to a curation problem, which would be the purview of aggregators rather than the registry itself. We do plan to track download counts (#95), so perhaps aggregators could sort by those numbers. Aggregators can also implement their own ratings systems to recommend the most popular (and presumably official) servers. And I suppose paid placement is another option. 💀

[joelverhagen]

(I am not on the registry team, just focused on it because I'm lighting up NuGet based MCP servers)
Agreed that this mostly goes to the clients that read the data and "project" the data into whatever UX they want.
Additionally, the server name is a reverse DNS name so the official OneDrive MCP server could perhaps have a name like com.microsoft.onedrive/mcp or something like that. This would mean that the owner of microsoft.com is publishing this OneDrive MCP server. I am not sure when non-GitHub package names will come in. Maybe for the first release per #100.

[patrick-rodgers]

Then from the registry standpoint the plan is to externalize the risk.

It would be worth thinking through the implications of that approach, where without some indicator of official releases the consumer (think non-tech person - what's DNS? what's a github package?) is potentially placing their content at risk.

Anyone should be able to build/publish servers, while also having a way to mark official releases would be nice.

[jonathanhefner]

Anyone should be able to build/publish servers, while also having a way to mark official releases would be nice.

How would the registry determine which packages are official and which are not? How would disputes be handled?

[patrick-rodgers]

npm has the organization model, which isn't flawless but groups things in a user understandable way.

[tadasant]

Say I am a consumer, I know nothing of tech, and I search for "OneDrive" in MCP registry and get 100 results - how would I make a choice? ... (think non-tech person - what's DNS? what's a github package?) is potentially placing their content at risk.

I don't expect consumers to use the Registry API. They should only interface with MCP clients and their Registry mirrors, which they are responsible for augmenting and curating to the level of sophistication that matches their target persona. I don't think we can solve trust at the right level of granularity for all MCP uses through to the end-consumers, so the only scaleable way to approach this is to federate out to the clients, who own the end-user UI's and can present them as they see fit (after augmenting them with their own notions of trust and curation/filtering).

[tadasant]

Sorry for the long delay while I was OOO, back on now.

I took a pass at addressing comments. The only notable sticking point is the SLA @toby. Happy to continue discussing if we're still not aligned, maybe we land this PR and carve that out to discuss separately?

[toby]

Yeah @tadasant let's do it. I can open an issue for further SLA discussion, but let's merge this for now.