Design the shared chart artifact

[sergical]

Part of #42

Blocked by #46

Question

Design the shared chart artifact: one HTML document that is simultaneously the MCP Apps ui:// resource for get_timeseries and the landing page's live demo.

Build it rough and concrete so it can be reacted to. Fixture data is fine at this stage.

Settled by #46 — the lead tool is get_timeseries, and the renderer should be written against the shared queryResultOutputSchema envelope rather than one tool's shape, because get_timeseries, get_breakdown and get_conversions all emit it. Do not design for compare_periods; its schema is bespoke and generalizes to nothing.

Constraints the prototype must respect:

• Self-contained, single document. No subresources. The apex shares a 60/min per-IP rate limiter with the MCP endpoints (Serve HTML at the Worker root without breaking /mcp or /internal #43), and an MCP Apps resource renders in a CSP-whitelisted sandboxed iframe.
• Theme-agnostic and resize-aware — it renders inside a host it does not control.
• It must read as the product, not as marketing. Visitors are meant to see exactly what they would see in Claude.

The constraint is the point. Find out whether it produces something good enough to headline a landing page — and if it does not, say so, because that finding invalidates the one-artifact decision and reshapes the map rather than being worked around.

Link the prototype from this issue as an asset.

[sergical]

Follow-up research on the 2026-07-28 core revision (this repo already runs it — @modelcontextprotocol/server 2.0.0, and src/server.ts:72 serves server/discover). Three additions to the contract this prototype implements:

1. Declare the extension in the server/discover result: capabilities.extensions["io.modelcontextprotocol/ui"]. Under 2026-07-28 the client advertises per-request at _meta["io.modelcontextprotocol/clientCapabilities"].extensions, not once at initialize.
2. Do not emit the flat _meta["ui/resourceUri"] alias — the draft schema marks it deprecated and slated for removal before GA. Emit only nested _meta.ui.resourceUri.
3. Core-revision result obligations (resultType, ttlMs, cacheScope) apply to the ui:// resource's list/read results like any other.

Unchanged and confirmed current: ui:// + mimeType: "text/html;profile=mcp-app" + _meta.ui.{resourceUri,csp,permissions}. There is no 2026-07-28 Apps spec — extension versions are decoupled from core (SEP-2133), and Apps is still 2026-01-26 Stable.

Caveat for whoever builds this: the ext-apps draft still describes negotiation as happening in initialize (pre-stateless wording) while the core Extensions page shows per-request _meta. Unresolved in primary sources; prefer the core page.

[sergical]

Constraint carried over from the #43 research, since it lands on whoever builds this artifact:

src/worker.ts:32 sets X-Frame-Options: DENY on every response, and there is no frame-ancestors CSP anywhere in the Worker. DENY blocks framing even from the same origin. Anything that renders the artifact in an iframe served by this Worker — the landing page demo included — will get an empty frame until that header is scoped to the routes that actually need it.

This is not a reason to avoid an iframe. It is a header to narrow deliberately, with a note on which paths keep DENY. Whatever the artifact does with _meta.ui.csp, the host still has to be allowed to frame it.