Flint: Microsoft's chart spec language built for AI agents

Flint, Microsoft's new visualization language for AI agents, is interesting less for the charts it draws and more for the assumption baked into its design: the thing writing the chart spec is a language model, not a person. That single assumption changes what a good API looks like.

I read through the Flint project site and repo this morning. It's MIT-licensed, built by Microsoft Research with the IDEAS Lab at Renmin University of China, and it's worth ten minutes of your attention even if you never install it.

---

🧱 What Flint actually is

Flint is not a renderer. It's an intermediate language that sits above renderers. You hand it data, a set of semantic types, and a short chart spec. Its compiler works out scales, axes, spacing, labels, and legends for you, then emits a native spec for whichever backend you pointed it at.

import { assembleVegaLite } from 'flint-chart';

const spec = assembleVegaLite({
  data: { values: myData },
  semantic_types: { weight: 'Quantity', mpg: 'Quantity', origin: 'Country' },
  chart_spec: {
    chartType: 'Scatter Plot',
    encodings: { x: { field: 'weight' }, y: { field: 'mpg' }, color: { field: 'origin' } },
    baseSize: { width: 400, height: 300 },
  },
});

Swap assembleVegaLite for assembleECharts, assembleChartjs, assemblePlotly or assembleExcel and the input shape stays identical. That's the whole pitch.

Layer	Example	Who writes it
Rendering engine	Vega, Canvas, SVG	Nobody, by hand
Backend spec	Vega-Lite JSON, ECharts option object	Developers, painfully
Flint spec	chartType + encodings + semantic_types	An agent, or you

Key takeaway: Flint's real contribution is admitting that verbose config is a bad interface for a probabilistic author. Shrink the surface an LLM has to get right, and you get fewer broken charts.

---

💸 Why a smaller spec matters when you pay per token

Anyone who has asked a model to produce a full Vega-Lite spec knows the failure mode. It gets the encodings right and then hallucinates a property name three levels deep in config. You burn a call, you burn tokens, you retry.

Flint attacks that by shifting decisions from the model to a compiler:

• Fewer fields to hallucinate. Layout, spacing and legend placement are derived, not authored.
• Fewer output tokens per chart. A compact spec is cheaper to emit than a long one. I have not benchmarked the difference, and the repo doesn't publish a number, so treat this as a direction rather than a measurement.
• Validation before render. The MCP server exposes tools to create and validate a spec, so a bad chart can fail early instead of rendering as a mess.
• Semantic types do work. Flint ships 70+ of them, including Rank, Temperature, Price and Country. Telling the compiler a column is a country is more useful than telling it the column is a string.

If you're a student or a two-person team running on free-tier or prepaid API credit, that arithmetic is not academic. Retries are the quiet line item that kills a side project's budget.

---

📊 The Excel backend is the part I'd actually use here

Version 0.4.0, released 24 July 2026, added 38 Plotly chart types and 18 native, editable Excel chart templates. The Excel path goes through Office.js and produces a real Excel chart, not a picture of one.

I want to be blunt about why that matters in Sri Lanka specifically. Excel is the reporting language of most offices here. If your agent produces a PNG, the finance person cannot change the axis, cannot fix a mislabelled month, and cannot paste it into next quarter's workbook with new numbers. If it produces a native chart, they can.

Backend	Output	Best fit
Vega-Lite	Declarative JSON spec	Web dashboards, research figures
ECharts	Option object	Heavy interactive web UIs
Chart.js	Config object	Lightweight embeds
Plotly	Figure object	Scientific and statistical work
Excel	Native, editable chart	Reports handed to non-developers

That last row is the one that changes a workflow rather than a stack.

---

🛠️ How you'd wire it up

Install is ordinary npm. Node 18+ is required.

# library
npm install flint-chart

# MCP server for agents
npx -y flint-chart-mcp

The MCP server is the interesting half. It lets an agent create, validate and render a chart inside the same conversation where the question was asked, returning an interactive view, static PNG/SVG, or a backend-native spec. It can take rows inline as data.values, or read a local JSON, CSV or TSV file by data.url. For workflows without MCP, the repo also ships a standalone agent skill.

A realistic small-team setup:

1. Export your data to CSV from whatever system you already use.
2. Point the agent at the file through the MCP server.
3. Ask in plain English for the comparison you want.
4. Take the Excel or Vega-Lite output and edit it by hand where the machine guessed wrong.

Step 4 is not a failure. It's the point of a human-editable spec.

If your data starts as a spreadsheet, our free CSV to JSON converter will get it into the shape Flint's data.values expects.

---

⚠️ What I'd check before depending on it

This is early software and the repo does not hide it.

Signal	Status
Latest release	0.4.0, 24 July 2026
Version numbering	Pre-1.0
Python package	Source-only preview, not released
Research paper	Listed as coming soon
License	MIT

A warning worth taking seriously: four releases landed between 13 and 24 July 2026. That pace is a healthy sign for a young project and a bad sign for anything you need to keep stable for a year. Pin your version.

The other thing to weigh: Flint is an abstraction over five backends, so you inherit its opinions about what a good chart looks like. When those opinions are wrong for your data, you're debugging through an extra layer. For a one-off report, fine. For a product surface your users see daily, I'd still write the backend spec myself.

---

What this means for you

If you build with LLMs, the lesson here outlives the library. Design your machine-facing interfaces for the machine. Any place your agent has to emit a long, brittle config blob is a place you should be asking whether a compiler could derive nine-tenths of it from three inputs.

For everyday work, my read:

• Students and researchers — worth trying now. MIT license, no cost, and the Vega-Lite output slots straight into existing notebooks and papers.
• Small teams doing client reporting — the Excel backend is the reason to look. Test it against one real report before committing.
• Anyone shipping a production dashboard — watch it, don't adopt it yet. Pre-1.0 with a weekly release cadence is not a foundation.

And if what you actually need is a diagram rather than a chart, that's a different problem with different tools. Our own AI diagram generator handles flowcharts and architecture diagrams in the browser, free, no signup.

We spent fifteen years making chart libraries friendlier for humans. Flint bets the next stretch goes into making them legible to agents instead, with humans editing the output rather than authoring it. I think that bet is roughly correct, and a lot of tooling is about to get redesigned around it.