One persistent annoyance with asking LLMs to generate charts is the mismatch between what the model needs to say and what the renderer needs to receive. Vega-Lite is expressive, but it’s verbose and syntactically sensitive — a well-posed chart spec runs to dozens of fields the model has to fill in correctly, and wrong values often fail silently rather than producing an obvious error. The model knows you want a temporal heatmap with profit on the color scale; translating that knowledge into correct JSON is where things go wrong.

Flint, released by Microsoft Research on July 8, addresses this with a thin intermediate language. You give the compiler a short spec — chart type, which fields map to which visual channels, and semantic type annotations like YearMonth or Profit — and it derives the rest: temporal parsing rules, scale domains, axis tick formatting, color schemes, aggregation functions, and responsive layout. The resulting artifact can then be compiled to Vega-Lite, Apache ECharts, or Chart.js without any further changes to the source spec.

The semantic types are the interesting part. Rather than forcing the model to specify that a date axis needs "type": "temporal", "timeUnit": "yearmonth", and a particular axis format string, you annotate the field as YearMonth and the compiler infers all of it. This collapses the spec size considerably and moves the structural burden from the LLM to a deterministic compilation step — a good trade when the LLM’s strength is knowing what the chart should show, not knowing the exact Vega-Lite grammar for how to show it.

The numbers Microsoft cites are small but consistent. Across three models (GPT-5.1, GPT-5-mini, GPT-4.1) evaluated on TidyTuesday datasets, Flint-generated specs scored 16.27 / 16.16 / 15.91 against a direct Vega-Lite baseline of 15.91 / 15.60 / 15.34 on an LLM-judge scale. Not dramatic, but the direction is stable. The more compelling argument is probably qualitative: shorter, semantically typed specs have fewer places to go wrong, and when they do go wrong, the error is usually in the field mapping rather than buried in a formatting string the model hallucinated.

The project ships with two pieces: a flint-chart library for the compilation step, and a flint-chart-mcp server for integrating chart generation directly into agent workflows via the Model Context Protocol. That last part is practical — it means an agent working in any MCP-compatible environment can request a chart spec, generate Flint output, and get a rendered artifact back without leaving the conversation loop.

The idea generalizes beyond charts. Any domain where the output format is structured, low-level, and error-prone is a candidate for an intermediate representation that agents can target more reliably than the raw format. Flint is a small but well-scoped example of that pattern applied to a concrete pain point.