| Filename | Latest commit message | Latest commit date |
|---|---|---|
f32ecf0fe8<!-- Provide a brief summary of your changes --> ## Motivation and Context Currently there are a couple shortcomings I found in the server.schema.json: - It uses `https://json-schema.org/draft/2020-12/schema` which is unfortunately [not supported by VS Code](https://github.com/microsoft/vscode/issues/165219) - The Package schema does not require properties that are required by the service This means that need to round trip with the publish endpoint (perhaps spinning CI builds) to get the server.json right. It would be great if we could shift left and get indications in VS Code easier. I propose we downgrade the schema to `http://json-schema.org/draft-07/schema#`. The only difference for us is the name of `$def` pointers. I looked that [SchemaStore](https://github.com/SchemaStore/schemastore) and it looks like `draft-07` is by far the most popular. I believe the concession of using an older schema is worth it to get VS Code editor hints. Schema version | Count in SchemaStore -- | -- `http://json-schema.org/draft-04/schema#` | 292 `http://json-schema.org/draft-07/schema#` | 1972 `https://json-schema.org/draft/2019-09/schema` | 4 `https://json-schema.org/draft/2020-12/schema` | 4 <!-- Why is this change needed? What problem does it solve? --> ## Open questions - [ ] Should package `transport` actually be required? Or should `stdio` be assumed? - [ ] Should package `registry_base_url` be required? All of the examples have it it's not required by the publish endpoint. ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> I have tried the new schema inside VS Code and I get helpful warning. For example, these are the warnings for the old schema. <img width="1561" height="919" alt="image" src="https://github.com/user-attachments/assets/474170b8-acf8-4dca-a3d9-66c68c0d1902" /> I have run these: `go run .\tools\validate-examples\main.go` `go run .\tools\validate-schemas\main.go ` ## Breaking Changes I don't think these are breaking changes. I am expressing what the publish endpoint enforces at runtime. ## 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) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] 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 - [x] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions --> |
||
| .. | ||
| api | ||
| cli | ||
| server-json | ||
| faq.md | ||
| README.md | ||
Reference Documentation
Technical specifications and quick lookups for the MCP Registry.