Allow Implementations to optionally expose a websiteUrl and iconUrl
#417
Conversation
…Url` This proposed update to the specification allows MCP `Implementation`s to optionally declare a `websiteUrl` and `iconUrl`. Most MCP clients will render custom UI showing when an MCP server is used - for example, when one of the server's tools is invoked. Existing metadata allows clients to show a human-readable name for the tool (`ToolAnnotations.title`) and a name for the server `Implementation.name`). These changes will allow clients to render richer UI, showing a logo for the server (e.g. the GitHub logo for the [GitHub MCP server][1]) and linking to the server's website for more information. [1]: https://github.com/github/github-mcp-server
| */ | ||
| websiteUrl?: string; | ||
| /** | ||
| * The optional URL, pointing to an icon for this implementation. The URL should be accessible over the public internet, and should return a square (1:1 aspect ratio) PNG, with recommended dimensions of 512x512. |
There was a problem hiding this comment.
I am very open to being less opinionated about the file format - just a stake in the ground
There was a problem hiding this comment.
I wonder if quickly people would want to be able to provide different sizes to ensure proper rendering. The Web Manifest's handling if icons might be a reasonable pattern that could be useful here : https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Manifest/Reference/icons
There was a problem hiding this comment.
My thinking here was to keep it simple and just allow folks to specify one large icon, rather than supporting many resolutions. I'm flexible on this.
There was a problem hiding this comment.
I started out in your camp, @timrogers , thinking one-size icon should be used and scaled appropriately as needed. It keeps things simple.
But I think there's a reasonable argument to be made for allowing the definition of alternate scales, as @dsp-ant
suggests, since some icons/logos don't scale well up-and-down. I've worked on projects where the actual icon changes in nature depending on how much detail comes through at the target resolution. An icon at 32x32 (e.g. the Favicon dimensions) may look poor when certain details are included and down-scaled, so a simpler variant is used for those scales. But at 128x128 or 512x512, there's opportunity for tiny details to be rendered, so they could be included.
A good example comes from the Apple human interface guidelines.
The Safari icon at 512x512 shows tick marks. The 16x16 version isn't just downsampled. The tick marks are removed:
The nice thing about the PWA format is that it's still easy to define one single icon:
"icons": [ { "src": "icon/basic-icon.png" } ]
| @@ -272,11 +272,19 @@ export interface ServerCapabilities { | |||
| } | |||
|
|
|||
| /** | |||
| * Describes the name and version of an MCP implementation. | |||
| * Describes the MCP implementation. | |||
| */ | |||
| export interface Implementation { | |||
There was a problem hiding this comment.
I do wonder if this makes sense for only servers, or for clients too. I don't think there is a natural place in the spec today to put something server-specific.
| */ | ||
| websiteUrl?: string; | ||
| /** | ||
| * The optional URL, pointing to an icon for this implementation. The URL should be accessible over the public internet, and should return a square (1:1 aspect ratio) PNG, with recommended dimensions of 512x512. |
There was a problem hiding this comment.
I wonder if quickly people would want to be able to provide different sizes to ensure proper rendering. The Web Manifest's handling if icons might be a reasonable pattern that could be useful here : https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Manifest/Reference/icons
Co-authored-by: David Soria Parra <167242713+dsp-ant@users.noreply.github.com>
|
+1 I support this enhancement as it will significantly improve the user experience for MCP clients. A few suggestions:
These additions would maintain backward compatibility while providing richer UI capabilities for different display contexts. |
|
@timrogers would love to push this forward. i actually opened up my own PR not realizing this one existed (#862) — are you still actively working on it? if not happy to fork this version and add some variable icon sizes as @dsp-ant and @myaroshefsky suggested and shepherd it through |
|
@jesselumarie I'd love you to do that. Go ahead! |
|
Closing in favour of #955 |
This proposed update to the specification allows MCP
Implementations (servers and clients) to optionally declare awebsiteUrlandiconUrl.Motivation and Context
Most MCP clients will render custom UI showing when an MCP server is used - for example, when one of the server's tools is invoked.
Existing metadata allows clients to show a human-readable name for the tool (
ToolAnnotations.title) and a name for the serverImplementation.name) - but this leads to a not very rich, underwhelming UI.These changes will allow clients to render richer UI, showing a logo for the server (e.g. the GitHub logo for the GitHub MCP server) and linking to the server's website for more information, like the example below:
How Has This Been Tested?
N/A
Breaking Changes
No - the newly-added fields are optional
Types of changes
Checklist
Additional context