Flint is a free, open-source visualization language from Microsoft Research that lets AI agents produce polished charts from roughly 10 lines of JSON — no hand-tuning of axes, color ramps, or label spacing required. Instead of asking a model to write 100+ lines of fragile Vega-Lite or ECharts configuration, you tell Flint what your data means (semantic types like Quantity, Percentage, Country), and a deterministic compiler handles every geometric decision for you. It is MIT-licensed, installs with one npm command, and ships with an MCP server so Claude, Cursor, or any MCP-capable agent can generate, validate, and render charts directly inside the chat.
Last verified: 2026-07-30 · MIT-licensed · v0.4.1 on npm · 46 chart types · Compiles to Vega-Lite, ECharts, Chart.js, Plotly, and Excel · Built by Microsoft Research + IDEAS Lab at Renmin University
TL;DR — Should you use the Flint charting language?
- What it is: A TypeScript intermediate language where the LLM writes a compact spec (data + semantic types + chart type), and the compiler generates a complete, backend-native chart spec with all low-level parameters derived automatically.
- Why it matters: Chart generation is secretly two jobs — meaning (LLMs nail it) and geometry (LLMs struggle). Flint splits them so the model does the easy part and a deterministic compiler does the hard part.
- Who benefits most: Products where small or cheap models generate charts, composite chart types (waterfalls, sunbursts), and any system where end users see the output and 80% success isn't good enough.
- Who can skip it: If you have a frontier model and only need simple bar/line charts that it already one-shots reliably, Flint solves a problem you don't have.
- The bigger pattern: Flint is early proof that agentic systems converge on a shape where the LLM emits a tiny, validatable intermediate representation and a deterministic layer does everything else. If you build AI agents, this architecture is worth understanding even if you never make a chart.
What problem does the Flint charting language solve?
When you ask an AI agent to generate a chart, two very different jobs have to happen, and they require opposite skills. Job one is meaning — this column is month, that one is revenue, and the other is percentage change. LLMs are excellent at this. Job two is geometry — axis step sizes, scale domains, label spacing, color ramps, zero baselines, diverging palettes. LLMs are inconsistent at this, and the failure mode is predictable: the code looks right but renders a blank page or a broken axis. (Microsoft Research Blog, July 8, 2026)
The Flint team at Microsoft Research hit this wall in their own analytics agent — roughly 80% chart success rate. That sounds decent until a real user is on the other end and one in five charts is broken. Their insight was structural: stop blaming the model for a geometry problem, and give it a language where it never has to do geometry at all. (arXiv: 2607.20775)
The result is that Flint specs average 85% shorter than equivalent native backend code, according to the research paper's case analysis. A waterfall chart that balloons past 100 lines of coupled Vega-Lite parameters is about 10 lines in Flint — because the compiler owns every geometric decision the model would otherwise have to guess. (arXiv: 2607.20775)
How does Flint work under the hood?
Flint works by splitting chart creation into two separate specification sections that play to different strengths: a dataSpec that describes semantic meaning, and a chartSpec that describes the intended visual mapping. Here is what each part does and how the compiler wires them together.
The data specification — semantic types are the secret
Instead of treating fields as generic string or number, Flint defines over 70 semantic types — Temperature, Price, Quantity, Country, City, Rank, Percentage, Currency, Latitude, Longitude, and dozens more. When you tag a field as PercentageChange instead of number, the compiler knows to use a diverging color palette, format numbers as percentages, and set the domain midpoint at zero — all without you saying so. (npm: flint-chart; Microsoft Research Blog)
The dataSpec is created once per dataset and reused across every chart you build from it. In an agent workflow, the LLM infers the semantic types from column names, observed values, and context — then the same dataSpec is cached and reused as the user explores different visualizations. This improves token efficiency and makes iterative charting faster and more stable. (arXiv: 2607.20775)
The chart specification — describe intent, not pixels
The chartSpec is where you pick a chart type (bar, line, scatter, heatmap, sunburst, waterfall — 46 types total) and map fields to visual channels (x, y, color, size, facet). You say what the chart should show, never where the pixels go. The compiler takes the dataSpec + chartSpec and derives: parsing rules, scales and axes, aggregations, number formatting, color schemes, layout and cell sizing. (microsoft.github.io/flint-chart)
The compiler — a deterministic layer, not another model call
This is the core architectural insight. Flint's compiler is deterministic TypeScript — zero dependencies, zero model calls at render time. The LLM produces ~10 lines of JSON, the compiler turns that into a complete, native spec for whatever backend you choose, and no additional inference is needed to "fix" the output. This is what makes it reliable: the same input always produces the same output. (npm: flint-chart)
How to set up Flint with an AI agent in 3 steps
Installing Flint and connecting it to an agent like Claude through the MCP protocol takes about five minutes. Here is the shortest path from zero to a rendered chart.
Step 1: Install the Flint library
If you are building a JavaScript or TypeScript application and want to use Flint programmatically:
npm install flint-chart
The package has zero dependencies and ships type declarations for every entry point. It requires Node.js 18 or higher. (npm: flint-chart; GitHub: microsoft/flint-chart)
Step 2: Install the MCP server for agent use
The fastest way to use Flint with an AI agent is the MCP server. Add it to your MCP client config:
{
"mcpServers": {
"flint": {
"command": "npx",
"args": ["-y", "flint-chart-mcp"]
}
}
}
Or run it directly with npx -y flint-chart-mcp. It works with Claude Desktop, Cursor, VS Code, and any MCP client that speaks stdio. The server exposes five focused tools instead of one per chart type — a deliberate design choice that keeps the tool surface small enough for models to use reliably. (npm: flint-chart-mcp)
| Tool | What it does | Output |
|---|---|---|
render_chart |
Compiles + renders to image | PNG or SVG |
compile_chart |
Compiles to backend-native spec | JSON + warnings |
validate_chart |
Checks spec validity | Errors/warnings + computed size |
list_chart_types |
Lists available chart types per backend | Chart catalog |
create_chart_view |
Opens interactive chart panel | Live editable SVG UI |
Step 3: Write a chart spec and render it
Here is a real Flint chart spec — the kind an LLM can reliably produce from a natural-language request:
import { assembleVegaLite, type ChartAssemblyInput } from 'flint-chart';
const input: ChartAssemblyInput = {
data: {
values: [
{ region: 'North', revenue: 120 },
{ region: 'South', revenue: 90 },
{ region: 'East', revenue: 150 },
],
},
semantic_types: { region: 'Category', revenue: 'Quantity' },
chart_spec: {
chartType: 'Bar Chart',
encodings: { x: { field: 'region' }, y: { field: 'revenue' } },
},
};
const vegaLiteSpec = assembleVegaLite(input);
The same input compiles to any backend — swap assembleVegaLite for assembleECharts, assembleChartjs, assemblePlotly, or assembleExcel:
import { assembleVegaLite, assembleECharts, assembleChartjs, assemblePlotly } from 'flint-chart';
const vl = assembleVegaLite(input); // Vega-Lite spec
const ec = assembleECharts(input); // ECharts option
const cj = assembleChartjs(input); // Chart.js config
const pl = assemblePlotly(input); // Plotly.js figure
How does Flint compare to other AI charting approaches?
Flint is not the only way to get an AI agent to produce a chart. Here is how it stacks up against the alternatives that agents and developers actually encounter.
| Approach | Spec size | Reliability for complex charts | Local rendering | Tool count | Open source |
|---|---|---|---|---|---|
| Flint (Flint + compiler) | ~10 lines JSON | High (deterministic compiler) | Yes (in-process) | 5 MCP tools | Yes (MIT) |
| Direct Vega-Lite (model writes full spec) | 100+ lines | Medium for simple, low for complex | N/A (spec only) | — | Yes |
| Chart MCP servers (per-chart-type) | Varies | Low-to-medium (one tool per type) | No (remote rendering) | 26+ tools | Varies |
| Mermaid (flowcharts/diagrams) | Short | High for flowcharts | Local | — | Yes |
The chart MCP servers worth calling out: many expose one tool per chart type (26+ separate tools), each with a different schema, and they send your data to a remote render server. Flint gives you one schema that spans 46 chart types and renders locally — your data never leaves the host. The --disable-file-reference flag on the MCP server goes further: it rejects any local file references so only inline data is accepted, useful for untrusted or server deployments. (npm: flint-chart-mcp)
On the question of how Flint relates to existing tools: Flint does not replace Vega-Lite — it compiles to it. Vega-Lite is a high-level visualization grammar that feels manageable right up until you want a chart to look good, at which point a waterfall balloons past 100 lines of coupled parameters. Flint is an intermediate language that gets you 95% of the way there in a tenth of the code. You can hand-tune the compiled output if you need that last 5%. (Microsoft Research Blog)
Does Flint actually make AI agents better at generating charts?
Yes, but the margin is narrower than the headline numbers suggest. Microsoft Research benchmarked Flint against a baseline approach ("DirectVL") that asks models to directly write full Vega-Lite specifications. The evaluation used Tidy Tuesday datasets (63 tables across 51 real-world topics) and an LLM self-evaluation pipeline (LLM-as-judge). Results (scores out of 20):
| Model | Flint | DirectVL (baseline) |
|---|---|---|
| GPT-5.1 | 16.27 | 15.91 |
| GPT-5-mini | 16.16 | 15.60 |
| GPT-4.1 | 15.91 | 15.34 |
(Microsoft Research Blog, July 8, 2026)
The takeaway: Flint's advantage is consistency and conciseness, not raw chart quality on the best case. The real win is that the model produces much shorter programs (85% fewer lines), the specs are validatable before rendering, and complex chart types like waterfalls and sunbursts — where direct Vega-Lite generation falls apart — become reliable. The benchmark margin is modest because frontier models already one-shot simple charts acceptably. The value compounds when you use smaller/cheaper models, need composite chart types, or ship a product where users see every chart and 80% isn't good enough.
What are Flint's current limitations?
Flint is a two-month-old research project, not a finished product. Here are the caveats as of July 2026:
| Limitation | Detail |
|---|---|
| Not production-hardened | Version 0.4.1, active development, bugs still being caught — including cases where the same spec rendered differently across backends. (GitHub: microsoft/flint-chart CHANGELOG) |
| No maps | No geographic map charts (choropleth, etc.) yet. |
| No 3D or network graphs | The supported set is 46 flat chart types. |
| No layering | You cannot layer multiple marks on the same chart yet. |
| No Python package | A Python port exists as source-only preview in the repo, but no pip package has been published. (GitHub: microsoft/flint-chart) |
| Accessibility is an open issue | The GitHub issue for accessibility support is essentially empty — not yet addressed. (GitHub: microsoft/flint-chart issues) |
Why the Flint architecture matters beyond charts
The most important thing about Flint may not be charts at all. If you build AI agent systems, you should pay attention to the pattern it embodies, because it is appearing everywhere in 2026 agentic tooling: the LLM emits a tiny, validatable intermediate representation, and a deterministic layer does everything else.
You can validate 10 lines of JSON before it renders. You cannot validate 100 lines of generated D3 or Vega-Lite. This is the same insight that drives MCP servers to expose small, typed tool surfaces instead of open-ended code generation, and the same separation of concerns that makes loop engineering for agents safe. When the model's output is a constrained IR rather than free-form code, you get:
- Validatability — parse and type-check before execution
- Determinism — same input, same output, no model-call variance
- Token efficiency — 10 lines vs 100, lower latency, lower cost
- Editability — a human can tweak the IR by hand without understanding the compiled output
If you are building multi-agent AI team orchestration or any system where agents produce artifacts that must be reliable, the Flint pattern — "LLM writes intent, compiler writes execution" — is a design principle worth applying beyond visualization. You can find a similar principle at work in how DSPy separates the task from the model: define the program structure deterministically, let the model fill the semantic gaps.
What this means for you
If you build AI products that generate charts, install Flint today and try it with a small model. The MCP server setup takes five minutes, and you will immediately see whether your chart success rate jumps. The sweet spot is composite chart types and workflows where users see the output directly.
If you build agent infrastructure, study Flint's architecture even if you never render a chart. The pattern of constraining model output to a validatable IR and delegating execution to a deterministic compiler is a reliability strategy that scales to any domain where agent output must be trustworthy. This is the core of what makes AI agent OS architecture robust.
If you just need a one-off chart, use matplotlib or ask a frontier model for Vega-Lite directly. Flint is too much tool for a single bar chart — its value shows up at volume and in production pipelines, not one-off analysis.
FAQ
Q: Is the Flint charting language free and open source?
A: Yes. Flint is MIT-licensed and lives at github.com/microsoft/flint-chart. Both the core library (flint-chart) and the MCP server (flint-chart-mcp) are free to use with zero runtime dependencies. (npm: flint-chart)
Q: Can the Flint charting language be used without an MCP client?
A: Yes. The flint-chart library works standalone in any Node.js or TypeScript project. The MCP server is an optional convenience for agent workflows — it wraps the same compiler into a chat-callable tool. (GitHub: microsoft/flint-chart)
Q: What chart types does Flint support? A: Flint supports 46 chart types across 83 gallery examples, including bar, line, scatter, heatmap, sunburst, waterfall, area, boxplot, lollipop, pie, and grouped bar charts. It does not yet support maps, 3D charts, or network graphs. (microsoft.github.io/flint-chart)
Q: How much shorter are Flint specs compared to writing Vega-Lite directly? A: On average, Flint specifications are 85% shorter than equivalent native backend code, according to the research paper's case analysis. A waterfall chart that takes 100+ lines of Vega-Lite is roughly 10 lines in Flint. (arXiv: 2607.20775)
Q: Does Flint send my data to a remote server?
A: No. The MCP server renders locally and in-process — your data never leaves the host. You can further lock down file access with the --disable-file-reference flag, which rejects all local file references and only accepts inline data. (npm: flint-chart-mcp)
Q: Is the Flint charting language production-ready? A: Not yet. As of July 2026 it is at version 0.4.1 and still in active research development. Known bugs include cross-backend rendering inconsistencies. It already powers Microsoft's own Data Formulator tool internally, which gives it a real customer keeping it alive — but review the changelog and test in your environment before using it in critical paths. (Microsoft Research Blog; GitHub CHANGELOG)
Discussion
0 comments