[nishantmonu51]

Renders create_chart results as interactive charts inside Claude and ChatGPT through MCP Apps, with the chart specs compiled by Flint.

• The MCP server registers a ui://rill/widget/<hash>.html resource (a single-file Svelte + Vega bundle from the new web-mcp-app workspace, embedded in the binary) and links it from create_chart via _meta.ui. Hosts without MCP Apps support keep the markdown table and the "Open in Rill" link.
• External clients call create_chart with a Flint chart_spec plus a Rill data binding (metrics view, time range, filter, grain). The server resolves the query through chartquery (per-channel top-N budgets, comparison folds) and returns the rows, field metadata, semantic types and the project theme. The deprecated chart_type + spec shape is still accepted for clients holding a cached tool list.
• The widget compiles the spec with Flint on the client (the shared custom-viz/flint/compile.ts), follows the host theme (light/dark, fonts, style variables) and the project theme, and in fullscreen offers controls: time grain, top-N and comparison re-query through the app-only chart_data tool; chart type, layout and curve recompile locally. It reports its current view to the model via ui/update-model-context.
• "Open in Rill" replays the call into an Explore; the /-/ai/.../-/open route now maps Flint-shaped calls as well.
• Flint compile changes that canvas custom charts share: Rill's theme owns typography, colors and the color palette (Flint's config and tableau10 scheme no longer override it), multi-measure series are labeled with display names, row-faceted charts fill the box with upright row labels, derived axes take the measure's label and format, and discrete time axes are labeled at their grain.
• A built-in rill-charts skill (distilled from Flint's authoring skill) tells external clients which chart fits which question and the pitfalls to avoid; it is always-apply, so it arrives in the ai_instructions of list_metrics_views, and rill init --agent writes it alongside the other skills.
• Gated by chat_charts alone: it enables the chart tools and the widget, which every endpoint serves whenever the binary carries the bundle, and chart_data is advertised exactly where the widget is. chart_data calls count in the tool_call metric but are not persisted. Docs updated in docs/docs/guide/ai/mcp.md.

Tested with the Go suites (runtime/ai, chartquery goldens, runtime and admin MCP servers), the widget's vitest and Playwright fake-host suites plus its 650 KB size budget, the web-common Flint compile suite, and live in claude.ai (custom connector over a tunnel) and ChatGPT (custom MCP server), both in dark mode; light mode through the harness.

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

[djbarnwal]

Architectural review findings

1. One tool name, two schemas

MCPSpecProvider lets create_chart advertise a different input schema on MCP than in-app, under the same name. Those arguments are persisted to the same session tables, so every consumer of stored messages has to handle both shapes. Two separate tool names, or one schema, would remove that problem.

2. Feature gating is spread across four mechanisms

• chat_charts gates the tools.
• mcp_apps and the mcp_apps_enabled annotation gate the widget on the runtime endpoint.
• RILL_ADMIN_MCP_APPS_ENABLED gates the widget on the unified admin endpoint.
• The hidden chart_data gate is the user-agent prefix plus host-side enforcement of visibility.

The admin and runtime endpoints already disagree about when chart_data exists

3. Widget-driven query cost

Calls to chart_data aren't counted as billable tool calls, aren't persisted, and have no rate limit. A user flipping controls quickly, or a non-UI client calling the tool directly, can generate unlimited metrics queries. Queries are still tagged with the mcp source, but it's worth making a deliberate decision about metering and throttling here.

[djbarnwal]

The unified MCP server serves the widget and links create_chart to it based only on the RILL_ADMIN_MCP_APPS_ENABLED env var. The per-project mcp_apps flag and the mcp_apps_enabled annotation only apply to the direct runtime endpoint.

[nishantmonu51]

Gone: the unified server serves the widget whenever the binary carries the bundle, with no env var, and the per-project flag and annotation are removed. chat_charts is the only gate left.

[djbarnwal]

The direct runtime MCP server registers chart_data for every external client whether or not the widget is served, and ChartData.CheckAccess doesn't check mcp_apps. App-only calls are also left out of the tool_call metric and aren't written to the session.

[nishantmonu51]

Fixed: chart_data is now registered only when the widget is served, on both endpoints, and app-only calls count in the tool_call metric. They stay unpersisted on purpose, since they are widget plumbing rather than conversation turns.

[nishantmonu51]

Thanks, agree on all three.

1. One schema per tool name is the end state, and Flint is it. The in-app chat still advertises the native shape because its renderer is built on the native chart components, so moving it is a frontend change of its own. I'll do that as the immediate follow-up PR and delete MCPSpecProvider with it. Today the handler accepts both shapes on every channel and the replay route handles both; the only single-shape consumer is the in-app chart block, which never sees Flint calls until that follow-up. Separate tool names would keep two shapes in the tables under different names, so I'd rather not.
2. Collapsed to chat_charts. The widget is served wherever the bundle is embedded, and both endpoints now advertise chart_data exactly when they serve the widget. Removed mcp_apps, the annotation and RILL_ADMIN_MCP_APPS_ENABLED.
3. The queries behind chart_data were already metered as mcp requests; only the tool_call metric skipped them. It now counts them like any other data tool, still unpersisted. It has the same exposure as query_metrics_view, so I'd treat throttling as an MCP-wide question rather than add a widget-specific limit. The widget now debounces control changes and drops stale responses.

Rebased on main as well, so CI runs again.