i borrowed heavily from the the web manifest docs here 😅

Right now there are many types that extend BaseMetadata:

• Implementation
• Tool
• Resource
• ResourceTemplate
• Prompt
• PromptArgument
• PromptReference

I think websiteUrl is probably only appropriate for Implementation, and icons is probably only appropriate for Implementation + primitives (i.e. not PromptArgument nor PromptReference).

Also, websiteUrl will probably be covered by the upcoming server.json file. (See also modelcontextprotocol/registry#183.)

One alternative would be to create a dedicated Icons interface, and make the relevant types extend that interface.

Another alternative would be to add a new base type like SupremeDeluxeBaseMetadata that itself extends BaseMetadata and adds icons.

I think it's worth separating these out.

i'm happy to exclude websiteUrl from arguments/templates (I agree it doesn't make sense under PromptArgument or PromptReference).

The one nice thing about having URLs on all of these is you could potentially have deep links to sections for specific documentation e.g. link to a tool's docs. Right now the UI can get crowded with tool argument descriptions:

I'm unconvinced a separate icon type between URL or data icons is useful. A data URI is an entirely valid URL and it's easy to distinguish the two by looking at the scheme. Do we see the types here diverging further?

+1 to what @connor4312 suggested - it feels like this can be simplified.

Displaying arbitrary URLs is kind of annoying for web-based applications. Best practice to avoid leaking user IP's is to proxy an image through a proxy which is some work to set up and maintain, and is required for web applications using strict Content-Security-Policies

Creative idea: I wonder if we could say the URI here is an MCP resource URI and can be requested as such. That would also solve a potential difficulty where people would otherwise use data URIs reused between multiple prompts/types of data

Best practice to avoid leaking user IP's is to proxy an image through a proxy which is some work to set up and maintain, and is required for web applications using strict Content-Security-Policies

^ for this concern, couldn't folks use base64? I think putting it as a MCP resource URI is too prescriptive (and it's also something that is technically possible today https://modelcontextprotocol.io/specification/2025-06-18/server/resources#https%3A%2F%2F)

Yes, definitely, but this is a concern for client implementors and server implementors might not consider that when building their servers.

I don't have much better ideas here honestly aside from saying it can only be data URLs which is unpleasant 😕 One thing we could at least say is that, for streamable HTTP servers, the URL SHOULD be on the same origin as the server itself. For stdio servers we don't get though since a client doesn't know the path to the server entrypoint, just a command.

Maybe someone else will come along with more inspiration.

for streamable HTTP servers, the URL SHOULD be on the same origin as the server itself

^^ added this as part of the Icon type definition!

@jesselumarie in this context, should the URL be relative? That way we can make sure that the construction is always done against the origin.

one other annoying thing we'll have to look out for is XSS:
e.g. a URL like: javascript:alert('XSS');

added this as part of the Icon type definition!

I think I'm happy enough with this solution, we can resolve this comment :)