Flint MCP: Complete Guide (2026)

TL;DR + what you need

• What Flint is: a semantics-driven intermediate language (IL) — a compact format between a raw idea and a finished spec — for chart specs. You label what each data field means (a Country, a Rank, a YearMonth) and name a chart type; Flint’s compiler derives the scales, spacing, and layout that used to require hand-tuning.
• What flint-chart-mcp is: an MCP server, published on npm, that puts five tools in front of an agent — render_chart, compile_chart, validate_chart, list_chart_types, and create_chart_view.
• One command: npx -y flint-chart-mcp — no API key, no OAuth, nothing to sign up for.
• Its MCP Apps connection: create_chart_view is registered as an MCP App (the ui:// interactive-UI mechanism) with render_chart as the static-image fallback for hosts that don’t support it — see the section below.
• How new this is: the repo shipped July 8, 2026 and hit the Hacker News front page the same day. Everything in this guide is traced to the source, the official docs, or the launch thread — treat the API surface as early and likely to move.

Why Flint exists

Ask an agent for “a chart of monthly signups” and you get one of two failure modes. Keep the spec simple and you get a chart leaning on library defaults — cramped labels, an arbitrary color scale, bars in whatever order the data happened to arrive. Make the spec thorough and you get a wall of low-level Vega-Lite or ECharts JSON: explicit scales, explicit axis rotation, explicit spacing, verbose enough that adding one field means rewriting half the spec.

Microsoft Research’s framing, from the project launch post: building a polished chart normally forces a choice between a spec simple enough to generate reliably and a spec detailed enough to look right. Declarative grammars make this worse in one specific way — they work well when a field’s storage type matches its meaning, and get brittle the moment it doesn’t. The integer 202001 is a date, not a magnitude. A percentage-change column isn’t safe to stack. A sequential color ramp is the wrong choice for data that diverges around a midpoint. A human expert routes around these by hand; an agent either doesn’t know to, or burns its context budget trying.

Flint’s bet: separate what the data means from what picture you want, and let a compiler own the judgment calls that used to require a human expert. That is the whole idea in one sentence — everything else in this guide is the mechanics of it.

Mental model: three named pieces

The docs describe Flint’s compiler as a three-phase pipeline sitting between your annotated data and a backend-native spec:

   data + semantic_types            chart_spec
   ("what it means")             ("what to draw")
             \                        /
              \                      /
               ChartAssemblyInput (one object)
                        |
        ┌───────────────┼────────────────┐
        ▼                ▼                ▼
    Frontend         Optimizer       Code Generator
   (resolve          (physics-       (instantiate the
   encoding type,     based layout    backend-specific
   scale, color,       sizing)        template)
   sort from
   semantics)
                        |
        ┌───────────────┼────────────────┐
        ▼                ▼                ▼
    Vega-Lite          ECharts         Chart.js

• DataSpec — the data and semantic_types fields together. This is where the table lives and where each column gets a meaning; author it once per dataset and reuse it across charts.
• ChartSpec — the chart_spec field: which template (“Bar Chart”, “Scatter Plot”, “Heatmap”) and which field goes on which channel. During exploration, this is usually the only part that changes.
• Compiler — three phases per the project’s architecture docs: a Frontend that resolves encoding type, format, aggregation, scale, domain, and color from the semantic annotations; an Optimizer that does physics-based layout sizing (axis spans, band widths, aspect ratio); and a Code Generator that instantiates the Vega-Lite, ECharts, or Chart.js template.

Our read: the useful boundary here isn’t “simple vs. detailed,” it’s meaning vs. rendering. Once you accept that split, most of Flint’s design decisions follow from it directly.

Smallest end-to-end example

Every field name below is taken directly from the server’s Zod input schema, not paraphrased. A minimal validate_chart call for a three-row bar chart:

{
  "name": "validate_chart",
  "arguments": {
    "data": {
      "values": [
        { "region": "North", "revenue": 120 },
        { "region": "South", "revenue": 90 },
        { "region": "East", "revenue": 150 }
      ]
    },
    "semantic_types": {
      "region": "Category",
      "revenue": "Quantity"
    },
    "chart_spec": {
      "chartType": "Bar Chart",
      "encodings": {
        "x": { "field": "region" },
        "y": { "field": "revenue" }
      },
      "baseSize": { "width": 360, "height": 240 }
    },
    "backend": "vegalite"
  }
}

validate_chart returns whether the spec is valid, the resolved chart type, the computed layout size, and any warnings or errors — the same shape create_chart_view reads internally before it opens a preview:

{
  "valid": true,
  "chartType": "Bar Chart",
  "computedSize": { "width": 360, "height": 240 },
  "warnings": []
}

Swap the tool name to render_chart with the same arguments and you get a PNG or SVG back inline. Swap it to compile_chart and you get the raw Vega-Lite spec instead — useful when you want to hand-edit the output or feed it to a different renderer.

flint-chart-mcp: the five tools

The MCP server is Flint’s execution counterpart: the agent writes one ChartAssemblyInput, and the server compiles, validates, renders, or opens it locally. Here is the full tool surface, described exactly as the source registers them:

Beyond the five tools, the server also registers two resources and a prompt: flint://chart-types (a browsable JSON catalog), flint://agent-skill (a bundled markdown authoring guide the agent can load before it writes a spec), and an author_flint_chart prompt that injects that skill automatically. That is Tools, Resources, and Prompts — three of MCP’s core primitives, plus the Apps extension — from one server. See our MCP primer if those terms are new.

Install (every client)

The server is stdio-only today — your MCP client launches npx -y flint-chart-mcp as a local subprocess. No account, no token, no env block required for the default setup.

Claude Desktop / Cursor

Add this to your MCP client config (Claude Desktop: claude_desktop_config.json; Cursor: ~/.cursor/mcp.json, see /clients/cursor):

{
  "mcpServers": {
    "flint": {
      "command": "npx",
      "args": ["-y", "flint-chart-mcp"]
    }
  }
}

Claude Code

One line, via /clients/claude-code’s claude mcp add:

claude mcp add flint -- npx -y flint-chart-mcp

VS Code

VS Code’s workspace format uses a servers key and an explicit type. Add this to .vscode/mcp.json (see /clients/vscode):

{
  "servers": {
    "flint": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "flint-chart-mcp"]
    }
  }
}

By default the server can read local .csv, .tsv, and .json files the agent references by path in data.url. For an untrusted or hosted deployment, append --disable-file-reference to the args array — the agent must then pass every dataset inline via data.values, and local file reads are rejected outright.

After restarting your client, a good smoke test is asking the agent to call list_chart_types: if you get a catalog back, auth (or in this case, the absence of it) isn’t the problem for anything that fails later.

Flint vs. the MCP Apps spec

Short version: they compose, they don’t compete. Our MCP Apps spec deep dive covers the general mechanism: a tool result can point at a ui:// resource via _meta.ui.resourceUri, and a supporting host renders that resource as a sandboxed, interactive HTML UI instead of plain text. Flint doesn’t propose an alternative to that — create_chart_view is a working implementation of it.

The source is explicit about this. It imports registerAppTool and registerAppResource straight from @modelcontextprotocol/ext-apps/server (the Apps spec’s own SDK), points create_chart_view at a ui://flint-chart/chart-view.html resource, and hands the server these literal instructions:

Flint compiles one semantic chart spec (ChartAssemblyInput) into
Vega-Lite, ECharts, or Chart.js. By DEFAULT, prefer create_chart_view
to return an interactive, customizable chart whenever the host
supports MCP App UIs — it renders the chart live and lets the user
tweak it. Fall back to render_chart for a static PNG/SVG artifact only
when the host has no App UI support or the user explicitly wants a
static image. Use compile_chart for the backend spec JSON,
validate_chart to check a spec, and list_chart_types to discover chart
types and their channels.

That is capability detection, not a design choice made once and hardcoded. The same server offers the Apps-native path (create_chart_view, an interactive live preview with a tweak panel) and the plain-content fallback (render_chart, a static image) side by side, and lets the host’s declared support decide which one an agent should reach for. That is exactly the graceful-degradation pattern our Apps guide argues every UI-capable server should ship — “always ship a text fallback” is the line from that post, and Flint’s fallback happens to be a rendered image instead of text, which is a reasonable variant for a tool whose whole output is visual.

Our Apps deep dive names ECharts, VChart, and AntV’s MCP Server Chart as early UI-shaped chart servers. flint-chart-mcp is the newest entry, and arguably the clearest single-server illustration of the produce/render duality — both paths sit behind one shared spec instead of being two different servers with two different input shapes.

Recipes

Recipe 1 — From a query result to a live chart

“Chart this quarter’s revenue by region as a bar chart, and let me tweak it.” The agent maps the query result into data.values, annotates semantic_types (region as Category, revenue as Quantity), calls validate_chart to catch mistakes early, then create_chart_view to open the interactive preview. In a host without App support, the same prompt should fall back to render_chart for a static image — worth testing both paths if you support more than one client.

Recipe 2 — A static PNG for a report or CI artifact

“Generate a PNG of weekly signups for the changelog.” Same ChartAssemblyInput, but the agent calls render_chart directly with format: "png" and a fixed backend. Because rendering runs in-process on the machine hosting the MCP server, this drops cleanly into a script or CI step with no browser and no external rendering service in the loop.

What we got wrong

Three assumptions we made before reading the source, and what the code actually showed:

• We assumed “Flint vs. MCP Apps” was an either/or framing. It isn’t. create_chart_view is built directly on the Apps spec’s server SDK, with render_chart as the documented fallback. That’s composition, not competition — we had to read server.ts to find that out; it isn’t obvious from the README alone.
• We assumed “70+ semantic types” was loose marketing language for a label list. The schema says otherwise: a semantic type can carry an intrinsicDomain (e.g. a 1–5 rating scale), a unit, and a custom sortOrder, all of which change what the compiler emits. It behaves closer to a small type system than a tag.
• We assumed a same-week research repo would ship a thin, single-tool demo. Instead it registers five tools, two resources, and a prompt, with a Dockerfile and a real test suite in the same package. That is more MCP surface than several production servers we’ve covered on this site.

Gotchas & limits

• No remote transport yet. The server runs stdio-only via npx. An HTTP --transport flag was requested in issue #47 the day after launch and was still open as of this writing — a remote-hosted MCP setup needs your own wrapper today.
• Chart.js output is PNG-only. The tool descriptions say so explicitly: ask for SVG on the chartjs backend and you won’t get one. Use vegalite or echarts when you need vector output.
• Python isn’t installable yet. The repo includes a flint-py package, but the docs call it “a source preview” with PyPI publishing “planned for a later release.” Python-only agent stacks can’t pip install this today.
• Local file reads are on by default. Unless you pass --disable-file-reference, the server will read any local CSV, TSV, or JSON file the agent references by path. Fine for a personal coding session; worth locking down for anything multi-tenant.
• Wide-format, multi-series data needs reshaping first. A real early user hit this in issue #10: a table with one column per series (e.g. Sales Amount and Sales Amount by Due Date as separate columns) can’t be mapped onto one Line Chart encoding directly. Melt the table into one row per series-value first.

Who this is for

Community signal

The Show HN thread split cleanly between practitioners excited about the pattern and commenters skeptical of the “for AI agents” framing itself. Four voices, verbatim:

The thread also produced a real, fast community artifact: within a day of launch, a third-party developer published flint-chart-skill, an independent agent skill wrapping Flint, and posted it back into the HN thread as “tested.” That kind of same-day derivative is a better adoption signal than any comment count.

The verdict

FAQ

Glossary

• Flint — the semantics-driven intermediate language (IL) for chart specs; the project name for the whole effort.
• flint-chart — the npm package with the core compiler/library (JS/TS), importable directly into an app.
• flint-chart-mcp — the npm package that wraps the compiler in an MCP server for agents.
• Semantic type — a label like Country, Rank, or YearMonth that tells the compiler what a column means, not just its storage type.
• ChartAssemblyInput — the one object an agent authors: data + semantic_types + chart_spec (plus optional options and field_display_names).
• DataSpec — the data + semantic_types half of the input: what the table contains and what each column means.
• ChartSpec — the chart_spec half: which chart template and which field goes on which channel.
• Backend — one of Flint’s three compile targets: vegalite, echarts, or chartjs.
• MCP Tool — a named function an MCP server exposes that a model can call, like render_chart.
• MCP Resource — read-only content an MCP server exposes by URI; Flint uses flint://chart-types and flint://agent-skill.
• MCP App / ui:// resource — the MCP Apps extension mechanism for a tool to return a live, interactive HTML UI in a sandboxed iframe; Flint’s create_chart_view is one.
• Agent skill — a bundled instructions file (here flint-chart-author.SKILL.md) an agent loads before authoring specs, exposed as both an MCP resource and a prompt.
• stdio server — an MCP server launched as a local subprocess that talks JSON-RPC over stdin/stdout; how flint-chart-mcp runs today.

Sources

Primary

• github.com/microsoft/flint-chart — repo, README, source (MIT license, TypeScript)
• npmjs.com/package/flint-chart-mcp — the MCP server package
• npmjs.com/package/flint-chart — the core compiler/library package
• Microsoft Research — “Flint: A Visualization Language for the AI Era” (Chenglong Wang, Alper Sarikaya, Scott Tsukamaki, Michel Galley, Jianfeng Gao)
• microsoft.github.io/flint-chart — documentation site (overview, tutorials, API reference)

Community

• Show HN: Microsoft releases Flint, a visualization language for AI agents — posted by chenglong-hn (the project’s own lead researcher), July 8, 2026
• github.com/tcsenpai/flint-chart-skill — independent agent skill built on Flint, shipped within a day of launch
• GitHub issues referenced above: #10 (multi-series spec), #47 (HTTP transport)

Internal — read next

• /blog/mcp-apps-spec-2026-when-should-your-server-render-ui — the general framework behind create_chart_view
• /blog/best-mcp-servers-for-design-2026 — the wider roundup of design- and UI-adjacent MCP servers
• /blog/what-is-mcp — Tools, Resources, and Prompts, defined from scratch
• mcp.directory/servers — browse the full MCP server catalog