The news. On July 8, 2026, Microsoft Research open-sourced Flint, which it calls "a visualization intermediate language for AI-driven chart creation." The problem it targets: traditional chart libraries force a bad choice — short specs that "rely on system defaults" and look uninspiring, or "polished visualizations" whose specs are "verbose, fragile, and error-prone," which AI agents particularly struggle with. Flint has the agent write a compact semantic spec instead, and a compiler compiles it to Vega-Lite, Apache ECharts, or Chart.js. It ships with an MCP server so agents can create, validate, and render charts in a tool-using session. Read the release →
Picture a diner order ticket. A customer writes a few words — two eggs over easy, wheat toast — and the kitchen turns that into a plated dish, handling the pan heat, the timing, the plating. Nobody expects the customer to write out every step of the cooking. Today, though, an AI agent asked to draw a chart is basically forced to write the whole recipe itself: it has to emit a full, low-level chart specification, spelling out scales, axes, aggregations, colors, and layout by hand. That long, low-level spec is exactly where agents fumble — every extra property is another line that can be wrong, and a wrong line can break the chart.
Flint hands the agent a much shorter ticket. The agent writes only the load-bearing choices — the chart type, the semantic data types, and the channel mappings (which field goes on x, on y, on color) — and Flint's compiler derives everything else: the parsing rules, scales, axes, aggregations, formatting, colors, layout, and the final backend-specific spec. That compact ticket in the middle is the semantic intermediate representation: the agent states what it means, and the compiler works out how to render it. Because the same ticket compiles to three different kitchens — Vega-Lite, Apache ECharts, and Chart.js — the agent writes one spec and gets a chart in whichever library the app uses. And because it's exposed as an MCP server, the agent can create a chart, validate it, and render it without leaving its tool loop.
The deeper idea generalizes far past charts. When you shrink what an agent has to produce down to a small, checkable representation and let ordinary code fill in the brittle rest, you make its output more reliable — the same instinct behind an output filter that validates before anything ships. Microsoft even measured it: across three models, charts authored through Flint scored higher on its chart-quality benchmark than the same models writing Vega-Lite directly. The wins are modest and consistent, not dramatic — which is the point. The same models scored higher through Flint than writing the chart directly, so at least in Microsoft's test the improvement came from the interface, not a bigger model.
Where it earns its keep
Take one concrete request: "monthly new users as a bar chart, colored by plan tier." In Flint the agent commits to a handful of semantic choices: the chart type (bar), the fields bound to channels (period → x, newUsers → y, plan → color), and the semantic data types (say, period as a year-month and newUsers as a count). From those roughly five declarations (illustrative — the exact count varies per chart) — the chart type, a few channel mappings, and their semantic data types — the compiler derives the temporal scale for x, the linear scale and axis for y, the color palette for plan, the sum aggregation, the number formatting, the layout, and the full Vega-Lite / ECharts / Chart.js JSON. The agent's error surface shrank from a long list of low-level backend properties to roughly five semantic fields it can actually get right — and the same fields compile to any of the three libraries.
| Model | Flint spec | Direct Vega-Lite (baseline) | Source |
|---|---|---|---|
| GPT-5.1 | 16.27 | 15.91 | MSR |
| GPT-5-mini | 16.16 | 15.60 | MSR |
| GPT-4.1 | 15.91 | 15.34 | MSR |
Chart-quality score, higher is better; Flint edged the direct-Vega-Lite baseline on every model Microsoft tested. Absolute values are benchmark-internal.
Goes deeper in: AI Agents → Tool Use & Function Calling → Structured Outputs
Continue in trackTool Use → Structured Outputs — why narrowing an agent's output surface makes it reliableRelated explainers
Flint is one case of a broader pattern — constrain an agent's output to a small, checkable form and let ordinary code handle the rest — that these related explainers approach from other angles:
- SpatialClaw — code-as-action vs structured tool-calls — another take on how the interface an agent acts through, not the model, drives reliability
- AWS maps MCP tool-design tradeoffs — tool design as context engineering — Flint is exactly such a tool; how a tool's shape governs whether the agent uses it well
- MCP SEP-2663 — async task handles — the same protocol Flint's
flint-chart-mcpserver speaks