Tadas Antanavicius
Tadas Antanavicius
Some discussion here: https://github.com/modelcontextprotocol/registry/discussions/50 In the case where npm, pypi, etc. take down a package (e.g. in the case it is found to be malicious), we don't want to maintain...
To-do list: - [ ] Identify who will be financially responsible for maintaining deployment infrastructure - [ ] Set up at least production and staging environments - [ ] Set...
We have a [starting point](https://github.com/modelcontextprotocol/registry/blob/4f89a896ec37a9234792c3f2df5005e568fc0eee/tools/publisher/README.md?plain=1#L49) for this, but we should: - Formally define what is and is not valid in this JSON - Make sure we have some mechanism for...
We should draft these in this repository first, and then probably lift some references into the official docs just prior to go-live: - [ ] How to write your server.json...
Conceptually, we want: 1. An OpenAPI spec that represents the _full_ shape of the "registry API", including optional features like vendor-specific extensions. 2. An OpenAPI spec that represents the official...
One potential benefit of a centralized registry is that we could have `server.json` submitters list out all the possible tools their server may ever invoke, fingerprint them, and store those...
Pretty simple tweak, but one we should make to avoid overloading the `mcp.json` term.
Feels like a nice-to-have, but it would make sense to allow for [ServerCapabilities](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/623e37a3542ceaae0defe1a8450598b90ebbfbf2/schema/2025-03-26/schema.ts#L228) to be included in `server.json` data that can get surfaced back to API consumers.
While the initial scope of the official registry is of course MCP server-oriented, there is a (less pressing) need for similar functionality for MCP clients. Accomplishing this would allow us...