What Flint actually is
Flint is an open-source chart language from Microsoft Research, published under MIT. You write one declarative spec, called ChartAssemblyInput, and the compiler emits Vega-Lite, ECharts, Chart.js, Plotly, or a native Excel chart. It ships as an npm package (flint-chart) plus an MCP server (flint-chart-mcp) so an AI agent can create, validate, and render charts inside a conversation.
The problem it targets is specific. When an LLM writes chart code directly, the output is verbose and backend-locked, and it breaks easily. A structured intent format that a host can render against any of five backends is a saner contract. That is the pitch, and after a week wiring it into a small agent workflow, the pitch mostly holds.
Key features
One spec, five backends
The same ChartAssemblyInput compiles to Vega-Lite, ECharts, Chart.js, Plotly, and Excel. Web hosts pick whichever renderer they already ship. Excel output uses templates (18+ at the moment), which is narrower than the web targets but covers the common cases: bar, line, scatter, pie, combo.
Semantic field types
Flint ships 70+ semantic types like Rank, Temperature, Price, Country. You describe what a field means, not just its data shape. This gives the compiler enough context to pick a reasonable mark and scale, with a legend to match, without a human tuning every axis. For LLM generation this is the design choice that matters most.
Automatic layout
Sizing, label rotation, mark selection, and legend placement adapt to data cardinality. Ten bars get horizontal labels; forty get rotated ones. It is not magic, but it removes the fiddly decisions that make agent-generated charts look wrong.
MCP server
flint-chart-mcp wires directly into any MCP client, Claude and Cursor included. The agent gets three tools: create a spec, validate a spec, render to a chosen backend. No custom glue code, no prompt engineering to teach the model your chart schema.
Pricing breakdown
| Plan | Price | What you get |
|---|---|---|
| Free (MIT) | $0 | npm package, MCP server, full language spec, reference implementation |
There is one plan. It is free and MIT-licensed. Microsoft Research is not charging for this, and there is no hosted service to buy. Your costs are host implementation time and whichever renderer license you already carry (all five common backends are open-source or free for commercial use).
Pros and cons
Pros
- Multi-backend compilation genuinely works. One spec renders identically enough across Vega-Lite, ECharts, Chart.js, and Plotly for production use.
- MCP server drops into agent workflows with zero adapter code. Ten minutes from install to a working chart tool.
- Semantic types cut hallucination in generated specs. Rank is Rank, not "a number between 1 and 100 that means position."
- MIT license and active GitHub development mean you can fork and patch it, then ship without contract friction.
Cons
- The project is new. Community examples are thin, and third-party integrations do not exist yet outside the reference MCP server.
- Flint produces a spec, not pixels. The host application still has to run the target renderer. If you were hoping for a hosted render endpoint, that is not what this is.
- ChartAssemblyInput has a learning curve. It is more structured than "just call Chart.js," and hand-authoring is slower than the library it compiles to.
- Excel support covers 18+ chart templates, which is fewer than the web backends handle. If Excel output is the primary use case, check the template list before committing.
Who is it for
Three groups get real value from Flint today.
Agent builders who need charts as a first-class tool output. If your assistant produces reports and dashboards, plus ad-hoc visualizations, the MCP server removes a class of brittle prompt engineering. The agent describes intent; Flint handles the syntax.
Teams that ship the same data across web and Excel. One spec, both surfaces, no double maintenance. This is where the multi-backend compilation earns its complexity.
Platform teams standardizing chart output across multiple frontends. If half your app uses ECharts and half uses Plotly for historical reasons, Flint gives you one authoring surface without a rewrite.
Solo developers building a single-frontend product should skip it. If you already have Chart.js working, adding Flint is overhead. And if you need a hosted chart API rather than a spec language, this is not that product.
Verdict
Flint addresses a real gap. LLMs write brittle chart code, and the fix is a structured intent format the host can render reliably. The five-backend compilation and MCP integration make it practical to adopt today, not theoretical.
The honest limit is that whether Flint becomes a standard depends on host adoption, and that work is mostly ahead of it. Right now you are an early adopter, and early-adopter costs apply. Expect sparse examples and no community around it, and you will hit edges the reference implementation has not covered.
The rating is 7.6/10. Recommended if you are building agent workflows that produce charts, or you ship the same visualization across web and Excel. Wait six months if you want mature docs and a library of examples to copy from. The design is right; the ecosystem needs time.
