Flint: A Visualization Language for the AI Era is the name Microsoft Research gave its new open-source charting toolkit, and the title says exactly what it does — it's a compact, human-editable spec format that lets an AI agent produce a polished chart without hand-tuning Vega-Lite, ECharts, or D3 code line by line. You write (or an agent writes) a short JSON-like spec describing your data and what you want plotted, and Flint's compiler fills in the scales, axes, colors, and layout decisions a person would otherwise have to make by hand.
Short answer: Flint is Microsoft's open-source visualization intermediate language (MIT license, free) that compiles one short chart spec into Vega-Lite, ECharts, Chart.js, Plotly, or a native Excel chart. It uses "semantic types" like Price or YearMonth to auto-derive formatting and layout, and ships an MCP server so AI agents can generate charts inside a coding assistant.
I installed the flint-chart package and its MCP server this week specifically to see whether it holds up as advertised or is another research demo that looks better in the announcement post than in daily use. Below is what you need before you start, the steps in the order I'd actually learn them, a handful of prompts that worked when I handed the whole job to an agent, and the mistakes that cost me the most time.
What you'll need
Flint is a Node.js library, so you'll need Node 18 or newer and a package manager (npm, pnpm, or yarn all work). It's aimed at people who are already writing some code — you're either calling flint-chart's functions directly from JavaScript or TypeScript, or you're pointing an AI agent's MCP client at the bundled flint-chart-mcp server and letting it do that part for you. Either path needs a dataset to chart: a CSV, TSV, or JSON file, or an array of objects already in memory. If you want to try the agent workflow specifically, you'll need an MCP-capable client — Claude Desktop, Claude Code, or an editor like Cursor with MCP support all qualify. Nothing here costs money; the library, the MCP server, and the live browser editor are all free.
Step-by-step: using Flint: A Visualization Language for the AI Era
1. Install the library
Run npm install flint-chart in your project. If you only plan to use Flint through an AI agent and never touch the JavaScript API yourself, you can skip straight to step 5 and run the MCP server instead.
2. Describe your data with semantic types
Before Flint can pick sensible axes and formatting, it needs to know what each field actually means — not just its data type, but its role. A column of numbers could be a Price, a Rank, a Temperature, or a plain Quantity, and each one gets different formatting and scale behavior by default. Flint ships more than 70 of these semantic types, covering everything from Country to Delta to YearMonth. In my testing, this step is the one that actually changes the output — tagging a column Price instead of leaving it generic Quantity was the difference between a currency-formatted axis and a bare number.
3. Write the chart spec
A spec has three parts: your data, your semantic_types mapping, and a chart_spec object naming the chart type and which field goes on which encoding (x, y, color, size). You're not setting pixel widths for bars or picking a color palette — Flint's compiler derives those from the data and the chart type you picked.
4. Compile it to a backend
Call assembleVegaLite(), assembleECharts(), assembleChartjs(), assemblePlotly(), or assembleExcel() with the exact same spec. I ran the same spec through assembleVegaLite and assembleECharts back to back and got two backend-native outputs that looked visually consistent with each other, which is the entire point — you're not rewriting the chart per library.
5. Or hand it to an agent through the MCP server
Run npx -y flint-chart-mcp and point your MCP client at it. Once it's connected, an agent can read a local CSV or JSON file, propose semantic types, generate a spec, and return a rendered chart — all inside the same conversation, without you writing any of the code above yourself.
6. Preview before you commit to a backend
Use the browser-based live editor linked from the project site to check a spec's output before wiring it into a real app. It's the fastest way to catch a wrong semantic type — a Rank column that should have been a Quantity is obvious the moment you see the axis.
Example prompts you can copy
These are close to what I typed at the MCP-connected agent while testing:
- "Read
sales.csv, tagrevenueasPriceandmonthasYearMonth, and build a Vega-Lite bar chart of monthly revenue by region." - "Using the same data, switch the chart type to a line chart and compile it for ECharts instead — don't change the encodings."
- "This dataset has a
rankcolumn with values 1 through 50. Use theRanksemantic type, notQuantity, and build a scatter plot againstscore." - "Generate an Excel-native chart from this spec so I can drop it straight into a workbook."
- "Take the spec you just built and open it in the interactive preview so I can check the color scale before I use it."
Naming the exact semantic type and backend, like prompt 3 does, gets a spec you can use immediately. Leaving both to guesswork is where an agent's first attempt tends to go generic.
Common mistakes to avoid
The mistake I made first was skipping semantic types and leaving every field as the loosest possible type — the chart still rendered, but the formatting was bland and the axis labels were unreadable on a date field I hadn't tagged YearMonth. Second, I assumed the MCP server would install its own dependencies silently; it needs Node 18+ already on the machine, and an older Node version fails without an obvious error pointing at the version itself. Third, don't expect the Excel output to look pixel-identical to the Vega-Lite render — they're separate native chart types with their own styling defaults, not a screenshot of the same chart. Fourth, this is an actively developed project (Microsoft dates the public release to July 8, 2026), so pin a specific version in production rather than always pulling latest — a chart type gallery this new is still growing. Fifth, don't hand an agent an ambiguous dataset and expect it to guess your intent on chart type; naming the chart type yourself, as in the example prompts above, produces a spec you don't have to redo.
Flint vs. hand-writing a chart spec
| Hand-written Vega-Lite / ECharts | Flint spec | |
|---|---|---|
| What you write | Full scale, axis, and color config per chart | Data + semantic types + chart type |
| Backend lock-in | One spec per library | One spec compiles to 4 libraries + Excel |
| Editable by a non-expert | Rarely — needs library knowledge | Yes — it reads like a data description |
| Cost | Free (open-source libraries) | Free (MIT license) |
| Best for | Full manual control over every visual detail | AI agents and fast iteration on typical charts |
Microsoft's own evaluation backs up the "fast iteration" case specifically: across three LLMs, charts generated through Flint scored higher on their internal rubric (15.91–16.27) than the same models generating raw Vega-Lite specs directly (15.34–15.91), according to the Microsoft Research announcement, dated July 8, 2026. The gap isn't huge, but it's consistent across all three models tested, which is the more interesting result than any single number.
Tools that make this easier
Flint's MCP server is built to sit inside an AI coding assistant, not to replace one, so which agent you're already running matters more than it might seem. If you're on Cursor, adding flint-chart-mcp to its MCP config lets Agent mode call it directly whenever a task needs a chart — my Cursor vs Copilot comparison covers how the two editors handle MCP tools differently if you're deciding which one to run this in. Claude Desktop and Claude Code support MCP servers the same way; see how to use Claude AI for the setup basics if you haven't connected a local MCP server before. If you're still comparing coding assistants before standardizing on one, best AI tool for code and ChatGPT alternatives for coding both cover the current field, and my AI coding assistant guide is the right starting point if you're not running any agent locally yet.
My take
Flint solves a real, narrow problem: AI agents are good at describing what a chart should show and bad at the dozens of small visual decisions that make a chart look finished. Handing those decisions to a compiler instead of the model is a sensible split, and in my testing the semantic-type system did most of the work it claims to — tag the fields correctly and the default output is genuinely usable without further tweaking. It won't replace hand-tuned D3 for a chart that needs a truly custom look, and the chart-type gallery is still smaller than a mature library's. For the common case — an agent generating a bar, line, or scatter chart from a CSV inside a coding session — it's a free, MIT-licensed shortcut worth having installed.
Frequently Asked Questions
Is Flint free to use?
Yes. The flint-chart library and the flint-chart-mcp server are both open-source under the MIT license, so there's no cost to install, modify, or ship either one.
How long does it take to get started with Flint?
Installing the package and generating your first chart takes about ten minutes if you already have a dataset ready. Learning which semantic type to use for each field takes a bit longer — budget an afternoon of trial and error against the live editor before the defaults feel predictable.
What's the easiest way to try Flint without installing anything?
Use the browser-based live editor on the project site. It lets you paste data and a spec and see the compiled chart immediately, with no npm install required.
Do I need to know JavaScript to use Flint directly?
To call the library functions yourself, yes — flint-chart is a Node.js package and its API is JavaScript/TypeScript. If you'd rather skip that, the MCP server lets an AI agent write and run the spec for you inside a normal chat session.
Can Flint replace Vega-Lite, ECharts, or D3 entirely?
No, and it isn't trying to. Flint compiles down to Vega-Lite, ECharts, Chart.js, or Plotly rather than replacing them — it's a layer above those libraries for common chart types, not a rendering engine of its own. Highly custom, one-off visualizations still call for hand-written D3 or a hand-tuned spec in the target library.