feat(mcp): icons on server, tools, prompts, and resources - verify client rendering first #411

New issue

Open

opened 2026-08-17 15:47:05 +00:00 by hexajon · 1 comment

hexajon commented

2026-08-17 15:47:05 +00:00

Owner

Part of #412.

The MCP spec (2025-06-18 and later) defines icons arrays on tools, resources, prompts, and the server implementation. Claude Code's rendering of them is UNCONFIRMED. Bundle strings show that icon handling exists, but there is no verified display path. The terminal CLI may not render image icons at all, and the desktop app might. So this is investigate-first, build-second.

If icons render anywhere, the madtea icon is obvious: the 🎩🫖 hat-and-teapot, served as an SVG or PNG data URI. The spec allows data: URIs, which avoids a hosted-URL dependency. This would complement the earlier emoji-in-server-key display hack with a spec-proper channel, and it could eventually replace that hack if clients render implementation icons in the tool-call line.

Acceptance criteria

Empirical check: serve icons on the implementation plus one tool, one prompt and one resource. Record what Claude Code (terminal and desktop app) and at least one other client actually render. Comment the findings on this issue BEFORE building the full surface.
If icons render anywhere: ship the hat-and-teapot icon as a data URI on the implementation, tools, prompts and resources, sized per spec, with sizes and mimeType declared.
If icons render nowhere: close this issue with the evidence and a revisit trigger (client release notes that mention icons).
Add a docs/COMPAT.md note on which clients render icons.

Part of #412. The MCP spec (2025-06-18 and later) defines `icons` arrays on tools, resources, prompts, and the server implementation. Claude Code's rendering of them is UNCONFIRMED. Bundle strings show that icon handling exists, but there is no verified display path. The terminal CLI may not render image icons at all, and the desktop app might. So this is investigate-first, build-second. If icons render anywhere, the madtea icon is obvious: the 🎩🫖 hat-and-teapot, served as an SVG or PNG data URI. The spec allows `data:` URIs, which avoids a hosted-URL dependency. This would complement the earlier emoji-in-server-key display hack with a spec-proper channel, and it could eventually replace that hack if clients render implementation icons in the tool-call line. ## Acceptance criteria - [ ] Empirical check: serve icons on the implementation plus one tool, one prompt and one resource. Record what Claude Code (terminal and desktop app) and at least one other client actually render. Comment the findings on this issue BEFORE building the full surface. - [ ] If icons render anywhere: ship the hat-and-teapot icon as a data URI on the implementation, tools, prompts and resources, sized per spec, with `sizes` and `mimeType` declared. - [ ] If icons render nowhere: close this issue with the evidence and a revisit trigger (client release notes that mention icons). - [ ] Add a `docs/COMPAT.md` note on which clients render icons.

hexajon added the

enhancement

status/needs-verification

labels

2026-08-17 15:47:05 +00:00

hexajon commented

2026-08-17 15:47:12 +00:00

Author

Owner

Labelled status/needs-verification, because the next step needs a live interactive client session. The first acceptance criterion is to serve the icons and record what Claude Code (terminal and desktop app) and at least one other client actually render. Building the full icon surface before that check would violate the issue's own ordering, and everything after the probe depends on what the observation shows.

The plan is ready to run: a small probe branch that serves the 🎩🫖 icon as an SVG data URI on the server implementation plus one tool, one prompt and one resource, using the spec icons arrays with sizes and mimeType. Then I eyeball the terminal CLI, the desktop app and one non-Claude client, and comment the findings here. If nothing renders anywhere, this closes with the evidence and a revisit trigger, per the issue body.

This parks here until I run that probe in an interactive session.

Labelled status/needs-verification, because the next step needs a live interactive client session. The first acceptance criterion is to serve the icons and **record what Claude Code (terminal and desktop app) and at least one other client actually render**. Building the full icon surface before that check would violate the issue's own ordering, and everything after the probe depends on what the observation shows. The plan is ready to run: a small probe branch that serves the 🎩🫖 icon as an SVG data URI on the server implementation plus one tool, one prompt and one resource, using the spec `icons` arrays with `sizes` and `mimeType`. Then I eyeball the terminal CLI, the desktop app and one non-Claude client, and comment the findings here. If nothing renders anywhere, this closes with the evidence and a revisit trigger, per the issue body. This parks here until I run that probe in an interactive session.

hexajon referenced this issue

2026-08-17 15:57:36 +00:00

Epic: feat(mcp): adopt the full client-supported MCP spec surface - make madtea the best-behaved MCP citizen there is #412

hexajon referenced this issue

2026-08-17 15:59:04 +00:00

mcp: aim at the draft spec #414

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#411

No description provided.

Rows
Columns