microsoft/flint-chart: a semantic chart compiler for AI agents

The problem Flint targets: agents writing chart code they cannot tune

Ask a language model for a chart and you usually get a wall of backend parameters: explicit domain ranges, tick counts, legend padding, label rotation, mark sizes. Those values are guesses. They are also the part of the output most likely to be wrong, because they depend on the data cardinality and the canvas size, neither of which the model knows precisely. Flint's answer is to remove that layer from the agent's job. The README describes the input as a high-level semantic specification, with the library deriving scales, axes, spacing, labels and layout from the spec, the data and an optional theme. The author of a spec states what a field means, not how it should be drawn. That is a real division of labour rather than a prompt-engineering trick, and it is the reason the project exists as a separate language instead of a set of convenience wrappers around Vega-Lite. The intended users are agent builders and tool developers. The repository also ships agent-skills/ and an MCP server, which tells you the primary consumer is expected to be a model in a chat or coding environment, not a person typing chart code by hand.

How a Flint spec becomes a Vega-Lite, ECharts, Chart.js, Plotly or Excel artifact

The mechanism is a compiler with a fixed input shape and swappable output. Every backend accepts the same ChartAssemblyInput and returns the target library's native spec object, so the input does not change when you change the renderer. Inside that input, semantic_types maps each field to one of the 70+ semantic types the README lists, such as Rank, Temperature, Price or Country. That mapping is what lets the compiler make layout decisions the agent never states. A field typed as Country is treated differently from an untyped string when it comes to ordering and axis treatment. The second input is chart_spec, which carries the chart type, the field-to-channel encodings and a baseSize. The third is theme_spec, which sits beside chart_spec and governs presentation: layout, labels, legends, axes, mark geometry and typography. The README draws the line clearly, saying the chart spec defines what the chart means while the theme defines how that meaning is presented. Themes come as presets (the README names New York Times, Economist, Swiss and McKinsey), as a custom ThemeSpec, or inherited from another theme. Outputs are backend-native: a Vega-Lite spec, an ECharts option, a Chart.js config, a Plotly figure, or an editable Excel chart. The Excel path is the outlier. It produces a real workbook artifact rather than a JSON spec for a browser renderer, which is why the 0.4.0 release note counts 18 native, editable Excel chart templates separately from the 38 Plotly chart types added in the same release.

Installing flint-chart and compiling a first scatter plot

The README gives two install paths depending on whether you are calling the library or wiring an agent. The first installs the library into a JavaScript or TypeScript codebase.

npm install flint-chart

The second runs the MCP server for agents and MCP clients. The -y flag accepts the npx prompt so the command works unattended.

npx -y flint-chart-mcp

For a first real use, the README's library example imports assembleVegaLite and passes a ChartAssemblyInput. The data goes in under data.values, the field meanings under semantic_types, and the chart itself under chart_spec with a chartType, encodings and baseSize.

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 },
  },
});

What you get back is a ready-to-render Vega-Lite spec, not a rendered image. You still need a Vega-Lite renderer to draw it. Swapping backends means importing the corresponding assembler, and the README shows assembleECharts, assembleChartjs, assemblePlotly and assembleExcel all taking the same input object. If you would rather not run anything locally, the README points MCP clients at a hosted endpoint, https://flint.data-formulator.ai/mcp, and notes that a local MCP server is recommended for large datasets. In VS Code with GitHub Copilot the documented path is MCP: Add Server then HTTP; in Claude it is Customize, then Connectors, then Add custom connector.

Where Flint stops: backends, Python, and the limits of automatic layout

The most concrete limitation is coverage, and the README is explicit that chart types and themes do not arrive on every backend at once. Release 0.5.1 extended visual themes to the Plotly backend, which means themes were not available there before that release. Release 0.4.0 added 38 Plotly chart types and 18 Excel templates, so the Plotly and Excel surfaces were thin until late July 2026. If your chart type exists in Vega-Lite but not yet in the backend you have standardized on, Flint will not help you, and the README does not document a fallback path for unsupported combinations. The second limitation is language. The README states plainly that a Python package is to be released and that the current Python port is a source-only preview in this repo. The monorepo does carry packages/flint-py and a test:py script that runs uv run pytest, but a preview is not a supported distribution. Teams with Python services should treat Flint as a JavaScript dependency for now. The third limitation is the nature of the automation itself. Automatic layout is a trade-off, not a free win. When the compiler picks spacing, label placement and legend geometry from cardinality and canvas constraints, you give up per-chart control unless the theme system exposes the specific knob you need. The README describes themes as governing layout, labels, legends, axes, mark geometry and typography, which is broad, but it does not document an escape hatch for overriding a single derived decision while keeping the rest automatic. If your charts are hand-tuned one-offs, the semantic layer is overhead you will fight.

Flint against writing Vega-Lite or ECharts specs directly

The obvious alternative is skipping Flint and having the agent emit Vega-Lite or ECharts JSON directly. The difference in approach is where the layout decisions live. Direct emission puts every scale domain, axis tick and legend property into the generated output, which means the model must reason about them from the data description alone, and any correction has to be made to that generated JSON. Flint keeps those decisions in the compiler and leaves the spec small enough that a person can read and edit it. The cost is a dependency and a learning surface: you now maintain semantic type mappings and understand what the compiler infers. There is also a portability argument in the other direction. A Vega-Lite spec is a well-known format that other tools consume; a Flint spec is only useful to Flint. So the choice is roughly whether you value a compact, editable, backend-agnostic input more than you value emitting a widely understood format directly. For a single backend and a fixed set of charts, direct emission is simpler and has no compiler to keep current. For an agent that must produce charts across backends, or produce an editable Excel chart, the semantic layer is doing work you would otherwise have to prompt for repeatedly.

Maintenance, releases and what the MIT licence leaves open

The repository is not archived, and the last push was on 2026-09-10, about a week before this writing. The release cadence in the README is dense: 0.2.1 on July 13, 0.2.2 on July 15, 0.3.0 on July 19, 0.4.0 on July 24, 0.5.0 on August 5 and 0.5.1 on August 14, all in 2026. That is a fast-moving surface, and the practical upgrade cost follows from it. The input shape is designed to be stable across backends, but each release has added chart types and templates (38 Plotly types and 18 Excel templates in 0.4.0 alone), so a pinned minor version can lag behind the chart type you want. The monorepo has separate workspaces for packages/flint-js and packages/flint-mcp, plus a site workspace, and the root scripts build, typecheck and test them independently, so you can track the library without the MCP server if that is all you need. The project is MIT licensed, which permits commercial use and modification, but the licence says nothing about the hosted MCP endpoint at https://flint.data-formulator.ai/mcp. That endpoint is a service, not the licensed code, and the README does not describe its data handling or availability terms. Anyone sending real data through it should treat that as a separate question from the MIT grant on the repository.

Editorial conclusion

Adopt Flint if you are wiring an agent or an internal tool to a charting backend and want one input shape to cover several of them, or if you need editable Excel charts generated from the same spec. Do not adopt it if you need a stable Python package today (the README calls the port a source-only preview), or if your charts are one-off and hand-tuned. Before committing, verify that your target backend is covered by the chart type you need, that the theme you want exists as a preset or can be expressed as a ThemeSpec, and whether the hosted MCP endpoint at https://flint.data-formulator.ai/mcp is acceptable for your data or you need the local server.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/flint-chart on GitHub
3. Project website
4. README
5. Releases