Validate provided repositories are publicly reachable (PGA golf server's github link is wrong)

[cjellick]

I am not sure if this is the right way to report an issue with a specific server. I reviewed https://github.com/modelcontextprotocol/registry/blob/main/docs/guides/administration/moderation-guidelines.md and it does not explain how to report a problem with a server.

The com.pga/pga-golf entry has an invalid repository URL. It does not resolve - https://github.com/pgahq/mcp-pga-com.

Here's the full entry for what it's worth:

        {
            "$schema": "https://static.modelcontextprotocol.io/schemas/2025-07-09/server.schema.json",
            "name": "com.pga/pga-golf",
            "description": "PGA's official MCP Server for all things golf-related. Find a coach, play golf, improve your game.",
            "status": "active",
            "repository": {
                "url": "https://github.com/pgahq/mcp-pga-com",
                "source": "github",
                "id": "1004564607"
            },
            "version": "latest",
            "remotes": [
                {
                    "type": "streamable-http",
                    "url": "https://mcp.pga.com/mcp"
                }
            ],
            "_meta": {
                "io.modelcontextprotocol.registry/official": {
                    "id": "0a62b274-571c-45e9-8b04-5a122e6cc4f5",
                    "published_at": "2025-09-09T15:22:49.722230578Z",
                    "updated_at": "2025-09-09T15:22:49.722230578Z",
                    "is_latest": true
                }
            }
        },

[tadasant]

Thanks for reporting this! I think we should go one step further here and properly validate repository.url values to be not only valid/publicly accessible but also actually owned by the publisher. See: https://discord.com/channels/1358869848138059966/1414810008796926072/1414979953266790490

[Avish34]

@tadasant / @domdomegg do you mind if I pick this up? Looks like a genuine issue. I think we should even match the repo ID with the actual one to make the validation more concrete.

quick question - Are we also allowing private repos?

[domdomegg]

I think we probably can't allow private repos if we're going to validate them? My guess is that mcp-pga-com is probably a valid private repo, although idk.

Currently repository is optional I think, so maybe fine to say if it is there it must exist as a public repo?

fwiw npmjs I don't think validates repos, for comparison. So I don't think this is a crucial burning issue, but we could do it.

[mgyarmathy]

Hi 👋 -- author of com.pga/pga-golf here.

I can confirm that pgahq/mcp-pga-com is a valid private repository in our GitHub organization. It wasn't clear to me from the publishing guide whether or not it was necessary to include the URL in our server.json. After talking to @tadasant in Discord (thread), we agreed it was better to omit the reference the private repository.

From what I've gathered, other registries allow links to private repositories (e.g., RubyGems and npm), but it's fairly uncommon for someone to do this in practice.

[tadasant]

The case where it would be useful to validate is, hypothetical example:

• A service (like Smithery is now set up to do) automatically publishes an open source server to the registry's index
• The original author/maintainer wants to manage their own entry, so they separately (manually) submit their server

If I'm a registry consumer, it's confusing to me to know which one is "canonical". IMO the maintainer's manual submission should be elevated to de-facto canonical, not the auto-published platform's one. A good way to signal that would be to disallow Smithery from setting repository.url (unless the maintainer deliberately chooses to set their server.json to the ai.smithery/{slug} as the canonical name).

I think we could rely on a convention like name must match at the server.json available at repository.url + optional subfolder? Any qualms with that?

[tadasant]

One more thought here: I think there will be cases where someone wants to link their root GitHub repository, but the server.json is nested somewhere inside a folder. I think that would be a fine pattern to allow (as long as it is somewhere nested within subfolder, if subfolder is provided). But it does mean we would want to search subfolders for the server.json closest to the root, and perhaps fail the validation in the case that there are two server.json's at the same level.

[Avish34]

@tadasant That's a good point. We should rely in server.json present in the repo link. For private repositories, authors shouldn't add the repo URL in the server.json that they are going to publish. I hope my understating is right. If yes, then should we document this?

I will take another day to think about how better we can validate when we have same entries from different author.

Just a thought (unrelated to the issue) - Consider a scenario where the author is bumping up the server version in the registry with the same package details as of earlier? Should that be allowed? I mean server with same content (description, remote, packages) should be even allowed?

[tadasant]

For private repositories, authors shouldn't add the repo URL in the server.json that they are going to publish. I hope my understating is right. If yes, then should we document this?

Correct, and yes.

Just a thought (unrelated to the issue) - Consider a scenario where the author is bumping up the server version in the registry with the same package details as of earlier? Should that be allowed? I mean server with same content (description, remote, packages) should be even allowed?

I don't really see a reason to block that - just seems like extra work to maintain what "no changes" means (for example, they should be able to bump the schema version of server.json even if nothing else changes). Do you have some concern if we allow no-op bumps?