-
Notifications
You must be signed in to change notification settings - Fork 559
expose Server URL #130
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
expose Server URL #130
Conversation
|
@maorfr there is no Server.url field - were you looking at something else? I think you are looking for Repository.url. Or maybe you would advocate for addition of some sort of |
|
examples of existing
|
|
Thanks for flagging - the spec and examples in docs are the source of truth, so we should remove those errant examples unless we agree to add the field to the source of truth. |
|
i think a server url makes a lot of sense, to answer the question - |
This would be the Remote.url field. The use case that makes sense to me would be a "landing page URL" like https://zapier.com/mcp. We should discuss what the right naming would be for this, as
And maybe we would require this URL to match the reverse DNS verification in |
Another option is
This might be too onerous a requirement. I can imagine someone wanting to switch to a new domain after the fact. (Gotta grab that new |
Adds optional website_url field to the server.json schema allowing publishers to provide a url to the server's homepage, documentation, or project website. This provides a central link for users to learn more about the server. Particularly useful when the server has custom installation instructions or setup requirements. Issue: #183 PR: #130 Discussion: #274 ## Motivation and Context This change addresses the need identified in #130, #183 and #274 for a standardized way to direct users to an official landing page similar to `homepage` used in NPM ([example](https://www.npmjs.com/package/@modelcontextprotocol/sdk)). It is also serves as a viable option for MCP Servers that don't follow typical package manager patterns (e.g., embedded in a Desktop app). ## How Has This Been Tested? - Schema validation: All 13 example server.json files validate successfully against the updated schema - Go validator tests: Added additional test cases covering URL format validation and namespace matching - Run all checks: Updated example files to work with anonymous publishing and verified `make check` passes ## Breaking Changes None. The website_url field is optional and backward compatible with existing server.json files. ## Types of changes - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Documentation update ## Checklist - [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 Security considerations: - Website URL validation enforces that the domain matches the publisher's reverse-DNS namespace - HTTP/HTTPS protocols are required (no file:// or other schemes) - Validation is consistent with existing remote URL validation patterns
Motivation and Context
the
URLfield is documented but does not exist.How Has This Been Tested?
Breaking Changes
Types of changes
Checklist
Additional context