| Filename | Latest commit message | Latest commit date |
|---|---|---|
e0e51eae37<!-- Provide a brief summary of your changes --> ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> The following PR: * Adds a new `transport` type used in Package and Remotes * Added `docker` to the `runtime_hint` examples * Added support for templated URLs. It is available for streamable-http and sse transports for Packages. I didn't thought of reasons to have this for Remotes, but we can enable it if needed. * Added validation for templated URLs so we can ensure all referenced placeholder variables are available. * For streamable-http and SSE transport types the URL is now a required property * Updated the publisher init command to reflect these changes * Updated the seed.json file * Added unit tests for the transport type related changes * Updated the server.json schema and the external pkg structs to reflect the new transport type * Updated the examples Thanks to @kkkarthik for spotting it! 🙏 ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> Ran the tests locally ## Breaking Changes <!-- Will users need to update their code or configurations? --> Yes ## 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) - [ ] New feature (non-breaking change which adds functionality) - [x] 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. --> - [ ] 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> |
||
| .. | ||
| publisher | ||
| server-json | ||
| server-registry-api | ||
| admin-operations.md | ||
| architecture.md | ||
| design_principles.md | ||
| ecosystem-diagram.excalidraw.svg | ||
| faq.md | ||
| MCP Developers Summit 2025 - Registry Talk Slides.pdf | ||
| moderation-guidelines.md | ||
| new_package_registry.md | ||
| README.md | ||
| roadmap.md | ||
| terms.md | ||
| versioning.md | ||
Official Registry Documentation
This extends the main README.
Project Documentation
faq.md- Frequently asked questions about the MCP Registrydesign_principles.md- Core constraints and principles guiding the registry designroadmap.md- High-level roadmap for the MCP Registry developmentMCP Developers Summit 2025 - Registry Talk Slides.pdf- Slides from a talk given at the MCP Developers Summit on May 23, 2025, with an up-to-date vision of how we are thinking about the official registry.
API & Technical Specifications
openapi.yaml- OpenAPI specification for the official registry APIapi_examples.md- Examples of what data will actually look like coming from the official registry APIarchitecture.md- Technical architecture, deployment strategies, and data flowsserver.jsonREADME - description of theserver.jsonpurpose and schemanew_package_registry.md- steps to add a new package registry for local server packages