Replies: 1 comment 1 reply
-
First of all, great work. I was thinking about building something similar the other day so I might as well contribute to it instead. The scenario I was thinking of was to build a VS Code extension that would allow developers to simply use VS Code's command pallete to configure MCP servers without requiring them to edit VS Code settings file. This needs some kind of registry hosting all available MCP servers and an API that can be used to list all servers and then grab the correct configuration for each server. I believe this is a perfect fit for that scenario. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Discussion Topic
Please read #11 first.
As laid out there, the vision for the official metaregistry summarizes to the following:
It is for the last point that I wonder whether we are on track to serve that purpose, whether it's worth it, or maybe we just focus on the first two points and let the ecosystem figure out the third in a nonstandardized way (or perhaps build a standard separate from the centralized metaregistry? i.e. we drive a separate notion of "standardized API meant for closed ecosystems where the MCP client is the direct consumer").
I'd love to hear from folks who envision doing more with the official metaregistry than simply "surface all the MCP servers to my MCP client users": are we on track to fulfill your use case? Is this OpenAPI spec on track to do so?
Beta Was this translation helpful? Give feedback.
All reactions