"Marketing" data in official metaregistry

[tadasant]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

@sandy081 brought up suggestions to include displayName and icon into the API.

I am inclined to say we should keep these out of scope for the following reasons:

• They are non-critical pieces of data (hence me calling it "marketing" data), and minimizing surface area / complexity / maintenance burden is important for our design
• They increase surface area for spam and/or security problems (e.g. icon URLs)
• They are not actually that useful to end-clients, because a concept like displayName is hard to standardize; we wouldn't want to end up with keyword-stuffed Amazon.com-like product listings. The best clients will transform these names or not use them in order to optimize UX for their end-users
• Other package registries don't optimize for this either (for example, there is no displayName on npm)

Suggestions for clients and/or server metadata middlelayer services work around this gap in data:

• Fetch icons from the source_code reference (e.g. from the associated GitHub user or org's profile picture)
• Create a displayName by just stripping the reverse-DNS namespace from name and Title-ize the casing as-desired

[domdomegg]

I might push back a little - I think having these would be valuable additions to the registry (although I don't think they should be mandatory). On some of these points:

• They are non-critical pieces of data (hence me calling it "marketing" data), and minimizing surface area / complexity / maintenance burden is important for our design
  • Agreed with reducing surface area/complexity, but I don't think this is too much of a stretch. We also already have description, which feels somewhat similar?
• They increase surface area for spam and/or security problems (e.g. icon URLs)
  • I think this is true - but security problems are mainly an issue for downstream registries consuming this data. Other registries do support URLs, which are expected to be handled by clients with some care (e.g. Docker has icons, or npm has git urls)
• They are not actually that useful to end-clients, because a concept like displayName is hard to standardize; we wouldn't want to end up with keyword-stuffed Amazon.com-like product listings. The best clients will transform these names or not use them in order to optimize UX for their end-users
  • I think end-clients would generally find them helpful, and having all downstream clients have to generate their own names for the different MCPs is quite an ask.
  • We could set some standards on what you can put for names, and do some light moderation to enforce this.
• Other package registries don't optimize for this either (for example, there is no displayName on npm)
  • That's probably because they are quite dev optimised, but I think we want MCP to be much broader. E.g. salespeople who want to use the Salesforce MCP, or accountants who want a Quickbooks MCP, or HR professionals who want a Workday MCP... Registry should hopefully unlock and enable this, and for that I think we want pretty names.
  • Also PyPI, NuGet, and Maven ecosystems all do actually support package display names

[tadasant]

Since I wrote this, this SEP has started, and assuming it lands, I think could probably align on including icon. Centralizing server maintainers' management of their icon is helpful and a logo/icon is an objective piece of data.

I still don't feel good about displayName though, or the ensuing slippery slope of other marketing data --

They are non-critical pieces of data (hence me calling it "marketing" data), and minimizing surface area / complexity / maintenance burden is important for our design
Agreed with reducing surface area/complexity, but I don't think this is too much of a stretch. We also already have description, which feels somewhat similar?

description was contentious at the outset (in discussions with David and Justin; though to be fair they haven't updated their opinions on this for a few months now so I can't speak for them still holding this view). We strongly considered tying description to be synced with e.g. a canonical npm/pypi's package description so as to minimize the number of vectors like this we're introducing. So having that be free-form is already a concession on this front; I wouldn't use it as an example to repeat.

My argument for reducing surface area/complexity is from the POV of seeing this as a slippery slope. If we take displayName, I think we could apply the same logic to a long list of nice-to-have fields and the complexity for implementation, maintainence, documentation, moderation, security, spam considerations, and so on can blow out.

They are not actually that useful to end-clients, because a concept like displayName is hard to standardize; we wouldn't want to end up with keyword-stuffed Amazon.com-like product listings. The best clients will transform these names or not use them in order to optimize UX for their end-users
I think end-clients would generally find them helpful, and having all downstream clients have to generate their own names for the different MCPs is quite an ask.

I don't think we're asking them to do that much - the workaround is very reasonable IMO: Create a displayName by just stripping the reverse-DNS namespace from name and Title-ize the casing as-desired. And/or a third party will sell a service that centrally standardizes names for people (I would trust a third party standardizer to provide a better UX than the wild west of self-reporting).

I expect clients to find to be reliably a better UI/UX than SEO-stuffed displayName's like you get when you let authors decide how their product is listed on an aggregator:

We could set some standards on what you can put for names, and do some light moderation to enforce this.

I don't think we can moderate this from a resourcing perspective; we'd be relying on community reports and heuristics from that.

That's probably because they are quite dev optimised, but I think we want MCP to be much broader. E.g. salespeople who want to use the Salesforce MCP, or accountants who want a Quickbooks MCP, or HR professionals who want a Workday MCP... Registry should hopefully unlock and enable this, and for that I think we want pretty names.

That's true but IMO it's another reason to not try to unify displayName.

"Curl MCP Server" is something that makes sense to developers. But a salesperson might find it confusing - a better display name would be "Fetch Website MCP Server". Which one do you set as the maintainer? The best downstream clients will massage this data for their users.

I would be a little more on the fence if we had some limited global namespace for the name field such that I wouldn't be able to name my server what I want (e.g. curl-mcp-server is taken so I feel like I need to workaround it and name it curl-advanced-mcp-server and that's weird when it shows up as Curl Advanced MCP Server) -- but because of our DNS based namespacing you actually have complete freedom to name it as you please within your namespace.