"Publisher" data in official metaregistry

[tadasant]

@sandy081 asked:

May I know if the server definition supports a required publisher property? I remember @sridharavinash mentioning that this can be derived from the repository owner or org. If so then it makes sense that the server registry populates the publisher information in the server list and server response.

My response:

There was no current plan to include a publisher property -- it is just implied through the reverse-DNS name field. If you think it would be helpful to include, I would suggest opening a Discussion as that would be some net new requirements work that I think it'd be helpful to get more input on.

@sandy081:

Is the name field meant for the name of the MCP server, eg: @modelcontextprotocol/server-filesystem in which case the owner/publisher would be modelcontextprotocol right? If so, it would be helpful if the server registry resolves this information into a separate property with necessary details like publisher and publisherDisplayName, for eg

"publisher": {
    "name": "modelcontextprotocol",
    "displayName": "Model Context Protocol",
    "verified": true
}

I think the registry is the right one to resolve this information and leaving this to clients could cause falsy information. It is important for a user to know the publisher/owner of an MCP server. Hence it would be great if this can be included in the initial version.

[tadasant]

I think there a major issues here with the notion of "trust". We actually have no guarantees that the publisher is who they say they are. We've got the reverse DNS system planned, but all that is is a namespace.

Is the name field meant for the name of the MCP server, eg: @modelcontextprotocol/server-filesystem in which case the owner/publisher would be modelcontextprotocol right?

Not exactly. I expect the name of the official filesystem reference server (that you called @modelcontextprotocol/server-filesystem) to have a name in this registry of something like: io.modelcontextprotocol/filesystem.

"publisher": { "name": "modelcontextprotocol", "displayName": "Model Context Protocol", "verified": true }

I think introducing management of "displayName" at the "publisher" level would be a significant scope expansion for this project and introduce a lot of problems. For example, we would need to protect against me registering a domain called fakemicrosoft.com and then setting my displayName as "Microsoft (Official)".

[sandy081]

It seems one should log in to GitHub to register an MCP server. If so, then that user should be the owner of the MCP server right? Then, the registry should store that user information and pass it on to the client with the server data.

[tadasant]

GitHub OAuth exists in the publication flow simply to provide a centralized notion of authentication, plus a default namespace (io.github.*/*) for the name field for the case where the publisher does not want to register their own domain. In theory, we could have used an IdP like Auth0 or Stytch instead + set up something like io.modelcontextprotocol.community/* as a namespace instead.

The source code of an MCP server can be hosted elsewhere (like Gitlab), or not shared on any code repository at all (such as for a remote-only server). So we don't have an opportunity to lean on GitHub to manage a unique notion of publisher identity.

[sandy081]

Given this example that is listed in the repository

{
  "servers": [
    {
      "id": "a5e8a7f0-d4e4-4a1d-b12f-2896a23fd4f1",
      "name": "@modelcontextprotocol/servers/src/filesystem",
      "description": "Node.js server implementing Model Context Protocol (MCP) for filesystem operations.",
      "repository": {
        "url": "https://github.com/modelcontextprotocol/servers",
        "source": "github",
        "id": "b94b5f7e-c7c6-d760-2c78-a5e9b8a5b8c9"
      },
      "version_detail": {
        "version": "1.0.2",
        "release_date": "2023-06-15T10:30:00Z",
        "is_latest": true
      }
    }
  ],
  "next": "https://registry.modelcontextprotocol.io/servers?offset=50",
  "total_count": 1
}

So what is the recommendation for the clients to show some basic information like Name & Owner from above data?

[sandy081]

This is a sample of how an mcp server is shown to user without proper name, publisher and icon info. I would prefer the registry provides these details instead of client deriving.

[tadasant]

Given this example that is listed in the repository

Sorry, that example is not up-to-date. The corrected example would be:

{
  "servers": [
    {
      "id": "a5e8a7f0-d4e4-4a1d-b12f-2896a23fd4f1",
      "name": "io.modelcontextprotocol/filesystem",
      "description": "Node.js server implementing Model Context Protocol (MCP) for filesystem operations.",
      "repository": {
        "url": "https://github.com/modelcontextprotocol/servers",
        "source": "github",
        "id": "b94b5f7e-c7c6-d760-2c78-a5e9b8a5b8c9"
      },
      "version_detail": {
        "version": "1.0.2",
        "release_date": "2023-06-15T10:30:00Z",
        "is_latest": true
      }
    }
  ],
  "next": "https://registry.modelcontextprotocol.io/servers?offset=50",
  "total_count": 1
}

So the client is realiably capable of providing the following UI without additional metadata:

"Filesystem MCP Server" "by modelcontextprotocol.io"

[sridharavinash]

There are 2 ways to get owner/name info -

1. use the reverse DNS lookup entry , which is in the format io.<domain>.<owner>/<repo_name>
2. For GitHub repos , the url contains both those bits - https://github.com/<owner>/<repo_name>

[tadasant]

Just to flag: I would strongly discourage using the source code location URL for this use case. For example, the source code of the modelcontextprotocol.io of the filesystem server will live at https://github.com/modelcontextprotocol/servers, because it is a monorepo of many servers.

But name is reliable and already in scope for the registry work.

[sandy081]

@tadasant Sure, I can start with reverse DNS lookup of the name. May I know how you retrieved the label - "Filesystem MCP Server" - from above example?

[tadasant]

@tadasant Sure, I can start with reverse DNS lookup of the name. May I know how you retrieved the label - "Filesystem MCP Server" - from above example?

Ruby code example of what I mean:

name = "io.modelcontextprotocol/filesystem"
title = name.split('/').last.split('.').last.capitalize
display_title = "#{title} MCP Server"

Could get a little more fancy with the .split logic to support e.g. names with multiple /'s and/or names that are defined with redundancy like MCP or MCP server in the name itself. Only a handful of possibilities to account for.

name = "io.modelcontextprotocol/brave-search"
title = name.split('/').last.split('-').map(&:capitalize).join(' ')
display_title = "#{title} MCP Server"

[sandy081]

Is it possible that the server derive this information and send it as part of the response. This will give consistency across clients right?

[tadasant]

I don't feel great about the official registry getting opinionated on presentation elements based on denormalized data transformations. Some MCP clients may think it is important to retain the original name, like brave-search. Others will have a UI designed such that Brave Search is much preferred. Suffixing with MCP Server is also highly opinionated, so I certainly wouldn't want to include that.

It's not clear to me what benefit this would provide in trying to solve it for all MCP Clients if they are liable to present it in some unique way anyway (Brave Search vs. brave search vs. brave-search vs. Brave Search MCP Server) that is dependant on their unique UI design aesthetic.

[tadasant]

FWIW: I think it would be reasonable to start here by introducing something like:

{
  "publisher": {
    "id": "com.microsoft"
  }
}

And skip on the notion of displayName for now. We could use the name reverse-DNS mechanism for publisher.id. And in the future add some mechanisms to allow owners of those namespaces to manage a unified "displayName" property (though I still worry a bit about fakemicrosoft.com declaring their display name as Official Microsoft).

Should it be publisher or author? Recently discussed this with @domdomegg and @felixrieseberg as something important to DXT.

[KalleBylin]

I would vote for going with publisher. It clearly identifies the entity responsible for distributing the server, aligns with reverse-DNS verification, and avoids the ambiguity of author (which could mean the original developer, current maintainer, or others).

[domdomegg]

I would prefer publisher to author as well :)

[tadasant]

I'm good with publisher 👍

[rdimitrov]

@domdomegg @tadasant - hey, I think we can close this one as completed (addressed by #298)?

[tadasant]

@rdimitrov maybe I'm missing something, but I think those are two different things -- this ticket is about creating a publisher field about "who is the publisher". The only assertion we have about "who" is actually doing the publishing is the DNS verification flow we have, so the best we can do for now is:

{
  "publisher": {
    "id": "com.microsoft"
  }
}

I'm realizing this is confusing because we have introduced a separately and basically unrelated field also named publisher inside _meta. Should we rename that one? cc @domdomegg. Maybe that one should be publish or something like unverified?

[rdimitrov]

Ah, thank you, so this is about a separate property providing more details for the publisher/vendor.

Yeah, I think we can improve the naming, i.e. have "extensions" instead of the current "publisher" which would allow us to have "publisher" or maybe "vendor" for the use case described in this issue. Does that sound good?

[tadasant]

Proposed solution in https://github.com/modelcontextprotocol/registry/issues/356 (but this Issue should remain for the less urgent work of adding publisher to the top level)