-
Notifications
You must be signed in to change notification settings - Fork 581
Add documentation for the repository section #174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add documentation for the repository section #174
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
tadasant
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor thoughts, thanks for writing this up!
I like this doc -- I think we should probably eventually strive to turn all these shapes into formal SHOULD-MAY-MUST style specification writeups, and this is a nice in-between step.
|
Thank you! |
<!-- Provide a brief summary of your changes --> ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> Resolve #173 ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> Copilot fixed my spelling mistakes. ## Breaking Changes <!-- Will users need to update their code or configurations? --> None. ## 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 - [ ] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions --> Ideally the `id` would be populated by the publisher CLI tool "on the way out" and MCP Registry would validate the `id`, perhaps using the token used for auth in the case of private repositories.
Motivation and Context
Resolve #173
How Has This Been Tested?
Copilot fixed my spelling mistakes.
Breaking Changes
None.
Types of changes
Checklist
Additional context
Ideally the
idwould be populated by the publisher CLI tool "on the way out" and MCP Registry would validate theid, perhaps using the token used for auth in the case of private repositories.