SEP-973: Expose additional metadata for Implementations, Resources, Tools and Prompts #955
Conversation
schema/draft/schema.ts
Outdated
| /** | ||
| * A string that specifies one or more sizes at which the icon file can be used. | ||
| * Each size is specified as <width in pixels>x<height in pixels>. If multiple sizes are specified, they are separated by spaces; for example, 48x48 96x96. | ||
| * For vector formats like SVG, you can use any to indicate scalability |
There was a problem hiding this comment.
i borrowed heavily from the the web manifest docs here 😅
|
@jesselumarie Thanks for taking these changes forward. This looks great to me, and is something I'd love to implement in GitHub Copilot coding agent. |
|
I would love if this would have an accompanying Specification Enhancement Proposal, that we can then put forward to @modelcontextprotocol/core-maintainers |
dsp-ant
changed the title
schema/draft/schema.ts
Outdated
| /** | ||
| * An optional URL of the website for this implementation. | ||
| * | ||
| * @format: uri | ||
| */ | ||
| websiteUrl?: string; | ||
|
|
||
| /** | ||
| * An optional list of icons for this implementation. | ||
| * This can be used by clients to display the implementation in a user interface. | ||
| * Each icon should have a `kind` property that specifies whether it is a data representation or a URL source, a `src` property that points to the icon file or data representation, and may also include a `mimeType` and `sizes` property. | ||
| * The `mimeType` property should be a valid MIME type for the icon file, such as "image/png" or "image/svg+xml". | ||
| * The `sizes` property should be a string that specifies one or more sizes at which the icon file can be used, such as "48x48" or "any" for scalable formats like SVG. | ||
| * The `sizes` property is optional, and if not provided, the client should assume that the icon can be used at any size. | ||
| */ | ||
| icons?: Icon[]; |
There was a problem hiding this comment.
Right now there are many types that extend BaseMetadata:
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.
There was a problem hiding this comment.
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:
schema/draft/schema.ts
Outdated
| sizes?: string; | ||
| } | ||
|
|
||
| export type Icon = UrlIcon | DataIcon; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
+1 to what @connor4312 suggested - it feels like this can be simplified.
jesselumarie
changed the title
dsp-ant
changed the title
jesselumarie
force-pushed
the
jlumarie/add-icons-to-implementations
branch
from
bb0decf to
b5c7196
Compare
| /** | ||
| * An optional list of icons for this implementation. | ||
| * This can be used by clients to display the implementation in a user interface. | ||
| * Each icon should have a `kind` property that specifies whether it is a data representation or a URL source, a `src` property that points to the icon file or data representation, and may also include a `mimeType` and `sizes` property. | ||
| * The `mimeType` property should be a valid MIME type for the icon file, such as "image/png" or "image/svg+xml". | ||
| * The `sizes` property should be a string that specifies one or more sizes at which the icon file can be used, such as "48x48" or "any" for scalable formats like SVG. | ||
| * The `sizes` property is optional, and if not provided, the client should assume that the icon can be used at any size. | ||
| */ | ||
| icons?: Icon[]; |
There was a problem hiding this comment.
I think it may be worth factoring this out into an Icons interface, such that interface Implementation extends BaseMetadata, Icons (and likewise for the other interfaces). That way, the documentation for the icons property is shared / centralized.
schema/draft/schema.ts
Outdated
| } | ||
|
|
||
| interface Icons { | ||
| src: string; |
There was a problem hiding this comment.
what is src? It doens't have a comment.
| - An HTTP/HTTPS URL pointing to an image file | ||
| - A data URI with base64-encoded image data | ||
| - `mimeType`: Optional MIME type if the server's type is missing or generic | ||
| - `sizes`: Optional size specification (e.g., "48x48", "any" for scalable formats like SVG, or "48x48 96x96" for multiple sizes) |
There was a problem hiding this comment.
Should this be size instead of sizes?
| - `src`: A URI pointing to the icon resource (required). This can be: | ||
| - An HTTP/HTTPS URL pointing to an image file | ||
| - A data URI with base64-encoded image data | ||
| - `mimeType`: Optional MIME type if the server's type is missing or generic |
There was a problem hiding this comment.
It would be nice if this was mediaType instead as the term mimeType was replaced decades ago https://www.iana.org/assignments/media-types/media-types.xhtml
There was a problem hiding this comment.
I agree with you, but mimeType is consistent with other occurrences within our schema. For example, Resource.mimeType.
| /** | ||
| * An optional list of icons for this implementation. | ||
| * This can be used by clients to display the implementation in a user interface. | ||
| * Each icon should have a `kind` property that specifies whether it is a data representation or a URL source, a `src` property that points to the icon file or data representation, and may also include a `mimeType` and `sizes` property. |
There was a problem hiding this comment.
Where is this kind property? It's not in the schema.
There was a problem hiding this comment.
kind was from an earlier revision of the SEP (see #973 (comment)). I've submitted #1451 to remove that, plus a few other clean-ups.
Follow-up to modelcontextprotocol#955. This factors out an `Icons` interface to centralize the implementation and documentation of the various `icons` properties. This also cleans up the type docs a bit, including removing reference to a nonexistent `kind` property from an earlier revision of the SEP.
| "description": "Primary application entry point", | ||
| "mimeType": "text/x-rust" | ||
| "mimeType": "text/x-rust", | ||
| "icons": [ |
There was a problem hiding this comment.
Any reason that resource templates don't also have icons?
Follow-up to #955. This factors out an `Icons` interface to centralize the implementation and documentation of the various `icons` properties. This also cleans up the type docs a bit, including removing reference to a nonexistent `kind` property from an earlier revision of the SEP.
* mcp: support custom icons for servers, tools, resources Adopts modelcontextprotocol/modelcontextprotocol#955 Closes #265892 * fix
The project dependency on `@modelcontextprotocol/sdk` has been updated to the latest version, 1.19.1 (from 1.18.2) with PR #564 With this update we can take benefit of the new features introduced in the `@modelcontextprotocol/sdk`; modelcontextprotocol/modelcontextprotocol#955 One interesting feature is the icon support for MCP servers. With version 1.105 VSCode supports MCP Server icons; https://code.visualstudio.com/updates/v1_105#_mcp-specification-updates This PR configures Azure DevOps MCP Server to have Azure DevOps logo as it's icon. ## **Associated Risks** None ## ✅ **PR Checklist** - [x] **I have read the [contribution guidelines](https://github.com/microsoft/azure-devops-mcp/blob/main/CONTRIBUTING.md)** - [x] **I have read the [code of conduct guidelines](https://github.com/microsoft/azure-devops-mcp/blob/main/CODE_OF_CONDUCT.md)** - [x] Title of the pull request is clear and informative. - [x] 👌 Code hygiene - [x] 🔭 Telemetry added, updated, or N/A - [x] 📄 Documentation added, updated, or N/A - [x] 🛡️ Automated tests added, or N/A --------- Co-authored-by: Dan Hellem <dahellem@microsoft.com>
10 participants
Currently, prompts and tool descriptions are often concatenated within a namespace to assure there are no collisions e.g.
This change adds an optional
Iconsargument so that Implementations can identify themselves visually, as well as awebsiteUrlfor linking to documentation. It also adds icons to Resources, Tools, and Prompts.This PR consolidates @timrogers PR #417 and my PR #862, taking in feedback from @dsp-ant and @myaroshefsky to allow icons of multiple sizes.
Motivation and Context
While we can encourage MCP clients to only show the tool/prompt name, it makes it difficult to succinctly show in the UI that it's coming from a specified 3rd party source. Adding an icon would allow for better affordances for tool/resource/prompt source identification for users, and the website url can help client self direct to documentation.
How Has This Been Tested?
n/a
Breaking Changes
n/a
Types of changes
Checklist
Additional context
Would love to get this merged in so we can make it a bit easier to highlight where tools/resources are coming from 🙏🏻