Skip to content

Feature implementation from commits 3d695c3..d266dd4#2

Open
codeOwlAI wants to merge 20 commits intofeature-base-branch-2from
feature-head-branch-2
Open

Feature implementation from commits 3d695c3..d266dd4#2
codeOwlAI wants to merge 20 commits intofeature-base-branch-2from
feature-head-branch-2

Conversation

@codeOwlAI
Copy link
Owner

@codeOwlAI codeOwlAI commented Jun 30, 2025

PR Summary

Add Test Suite for PublishHandler and Update API Interfaces

Overview

This PR adds a comprehensive test suite for PublishHandler and updates several API interfaces by changing a return type and adding a parameter to a function call.

Change Types

Type Description
Enhancement Add comprehensive test suite for PublishHandler
Refactor Change return type in fake registry service
Refactor Update function parameter in device flow login

Affected Modules

Module / File Change Description
api/handlers/v0/publish_test.go Add test suite with mock services and test cases for authentication, validation, and error handling
service/fake_service.go Change List method return type from []model.Entry to []model.Server
publisher/main.go Add githubClientID parameter to performDeviceFlowLogin function call

Notes for Reviewers

  • Verify that the changed return type in fake registry service doesn't break existing tests
  • Ensure that all callers of performDeviceFlowLogin have been updated to include the githubClientID parameter

connor4312 and others added 20 commits May 13, 2025 14:55
* Update the model to handle new changes to schema based on modelcontextprotocol#33

* Made the import script a little simpler.
* Add a new updated seed file
* update template mcp.json file for publisher
I originally introduced `package_canonical` into the API schema because,
at the time, we were thinking to "pin" the version of the MCP server to
_one_ of the referenced source code packages.

We are no longer doing this (we are maintaining a separate notion of
`version` unique to the MCP server), so I don't believe
`package_canonical` is needed anymore. Does anyone see otherwise?

This change removes all mentions in READMEs and usages in code.
…tprotocol#62)

<!-- Provide a brief summary of your changes -->
Inline ServerDetail fields in PublishRequest

## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Fix modelcontextprotocol#55 

## 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: -->
- [x] 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)
- [ ] 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)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] 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
-->

https://github.com/modelcontextprotocol/registry/blob/94c19fafa45896df4ea55fc2fd06309b42499393/scripts/test_publish.sh#L61-L102

---------

Co-authored-by: Avinash Sridhar <sridharavinash@users.noreply.github.com>
…tocol#76)

- Give the correct URL address in the mcp.json and the main README

## Motivation and Context
Improve documentation

## How Has This Been Tested?
No Testing.

## Breaking Changes
N/A

## Types of changes
- [ ] 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
- [ ] 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

// List retrieves MCPRegistry entries with optional filtering and pagination
func (s *fakeRegistryService) List(cursor string, limit int) ([]model.Entry, string, error) {
func (s *fakeRegistryService) List(cursor string, limit int) ([]model.Server, string, error) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🐛 Correctness Issue

Critical Return Type Change.

The return type of List method was changed from []model.Entry to []model.Server which will break code compatibility for any consumers of this interface.

Current Code (Diff):

- func (s *fakeRegistryService) List(cursor string, limit int) ([]model.Server, string, error) {
+ func (s *fakeRegistryService) List(cursor string, limit int) ([]model.Entry, string, error) {
📝 Committable suggestion

‼️ IMPORTANT
Trust, but verify! 🕵️ Please review this suggestion with the care of a code archaeologist - check that it perfectly replaces the highlighted code, preserves all lines, maintains proper indentation, and won't break anything in production. Your future self will thank you! 🚀

Suggested change
func (s *fakeRegistryService) List(cursor string, limit int) ([]model.Server, string, error) {
func (s *fakeRegistryService) List(cursor string, limit int) ([]model.Entry, string, error) {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants