fix: validate server names to allow only single slash (#471)

[ossamalafhel]

Summary

Added validation to reject server names with multiple slashes, ensuring consistency between JSON schema pattern and API validation.

• Count slashes in parseServerName() and reject if > 1
• Add ErrMultipleSlashesInServerName error constant
• Add unit tests in validators_test.go
• Add integration test in publish_test.go

Motivation and Context

Fixes #471. The JSON schema regex pattern ^[^/]+/[^/]+$ only allows a single slash in server names, but the API validation was not enforcing this constraint. This inconsistency
allowed invalid server names like com.example/server/path to be published.

How Has This Been Tested?

• Unit tests added to verify slash validation logic
• Integration tests added to verify the publish endpoint rejects multi-slash names
• Tested various edge cases: trailing slashes, consecutive slashes, URL-like paths
• All existing tests pass

Breaking Changes

None. This change only adds validation to reject previously invalid server names that shouldn't have been accepted.

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)
• Documentation update

Checklist

• I have read the MCP Documentation
• 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

• The fix ensures server names follow the intended format: namespace/name (e.g., com.example/my-server)
• This validation aligns the API behavior with the existing JSON schema regex pattern
• Test coverage includes edge cases like com.example//server, com.example/server/, and a/b/c/d/e/f
• The error message clearly indicates the issue: "server name cannot contain multiple slashes"

[domdomegg]

Thanks! Maybe we could actually add it as regex validation on the API types, which would show up in the docs and align the specs more?

Happy to merge this for now though

[ossamalafhel]

Thanks! Maybe we could actually add it as regex validation on the API types, which would show up in the docs and align the specs more?

Happy to merge this for now though

Hi @domdomegg,

Thanks for the review and the great suggestion! I've added the regex validation directly to the API types as you recommended.

The pattern ^[^/]+/[^/]+$ is now on the Name field in pkg/api/v0/types.go, which should make the validation visible in the API documentation and align the specs with the backend validation.

This complements the existing validation logic nicely - clients can now see the expected format in the API docs, and we still have the detailed error handling in the backend.

Let me know if this looks good to you!

new PR here: #479