| Filename | Latest commit message | Latest commit date |
|---|---|---|
d461400055The following PR adds a new server `status` field to support the status of servers, like deprecated or active Details: * Add status field to server.json schema with 'active' and 'deprecated' values * Update OpenAPI spec to include status field in Server responses * Add ServerStatus enum and field to Go model structs * Update examples to demonstrate status field usage (`active` and `deprecated`) Since this is my first PR there's a good chance I might have missed something so I'll appreciate any feedback to make this and any PRs in the future easier for you to review 😃 Fixes: #181 ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> The main goal is to have a way for server authors to notify registry consumers that a server may no longer be maintained and shouldn't be considered for using. ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> ## Breaking Changes <!-- Will users need to update their code or configurations? --> ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [x] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [ ] My code follows the repository's style guidelines - [ ] New and existing tests pass locally - [ ] I have added appropriate error handling - [ ] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions --> --------- Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com> Co-authored-by: Tadas Antanavicius <tadas@tadasant.com> |
||
| .. | ||
| examples.md | ||
| official-registry-openapi.yaml | ||
| openapi.yaml | ||
| README.md | ||
Registry API
There are a variety of use cases where an MCP Server Registry API is useful to the MCP ecosystem. At least the following:
- Implementation of a centralized, publicly available catalog of all publicly accessible MCP server implementations
- Implementation of a private catalog of MCP server implementations exclusively accessible by a specific group of people (e.g. a single enterprise)
These scenarios would benefit from a standard "MCP server registry API" specification that they could potentially compose, as well as share resources (like SDK implementations).
The centralized, publicly available catalog ("Official MCP Registry") needs additional constraints that need not apply to the broader "MCP server registry API"
References:
- openapi.yaml - A reusable API specification (MCP Server Registry API) that anyone building any sort of "MCP server registry" should consider adopting / aligning with.
- examples.md - Example manifestations of the OpenAPI specification
- official-registry-openapi.ayml - The specification backing the Official MCP Registry; a derivative of the MCP Server Registry API specification.