Skip to content

Conversation

@maorfr
Copy link

@maorfr maorfr commented Jun 5, 2025

Motivation and Context

the URL field is documented but does not exist.

How Has This Been Tested?

Breaking Changes

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

@tadasant
Copy link
Member

tadasant commented Jun 5, 2025

@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 learn_more_url or marketing_url on Server. Which is a reasonable discussion to have, however that is not in the documentation yet, so we'd need to start there. Do you have a use case?

@maorfr
Copy link
Author

maorfr commented Jun 5, 2025

examples of existing url:

@tadasant
Copy link
Member

tadasant commented Jun 5, 2025

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.

@maorfr
Copy link
Author

maorfr commented Jun 5, 2025

i think a server url makes a lot of sense, to answer the question -
where can you find a running instance of this MCP server? (think of a registry running within an org)

@tadasant
Copy link
Member

tadasant commented Jun 5, 2025

where can you find a running instance of this MCP server?

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 url is clearly too ambiguous (that is evident even from just this conversation). Some options:

  • landing_page_url
  • marketing_url
  • learn_more_url
  • more_information
  • canonical_url

And maybe we would require this URL to match the reverse DNS verification in name.

@jonathanhefner
Copy link
Member

jonathanhefner commented Jun 5, 2025

We should discuss what the right naming would be for this, as url is clearly too ambiguous (that is evident even from just this conversation). Some options:

Another option is homepage. That's what NPM (example) and RubyGems (example) use, at least when displayed.

And maybe we would require this URL to match the reverse DNS verification in name.

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 .ai TLD! 🔥)

@maorfr maorfr closed this Jun 8, 2025
@tadasant tadasant mentioned this pull request Jun 9, 2025
4 tasks
domdomegg pushed a commit that referenced this pull request Sep 11, 2025
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
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.

3 participants