antvis/mcp-server-chart: chart generation over MCP, and what it does not do

The problem: an LLM can describe a chart but cannot draw one

A language model is good at reading a table and deciding that a line chart fits better than a bar chart. It cannot produce a PNG. antvis/mcp-server-chart fills that gap by registering chart generation as Model Context Protocol tools, so a chat client that speaks MCP can call generate_line_chart or generate_sankey_chart and receive a rendered image instead of a description.

The audience is narrow but real. You need an MCP-capable client (the README names Claude, VSCode, Cline, Cherry Studio and Cursor), a Node runtime on the machine, and a willingness to let a tool choose chart types. If you are building a dashboard that must match a brand style guide pixel for pixel, this is the wrong layer. The README lists 26 tools covering statistical charts, relationship diagrams and geographic maps, and the project describes itself as usable for both chart generation and data analysis.

How the MCP tools map onto AntV renderers

The repository is a TypeScript package. package.json declares a bin entry named mcp-server-chart pointing at build/index.js, and the runtime dependencies are the MCP SDK, axios, cors, express and zod. That set tells you most of the architecture: the server is an express process that speaks MCP, validates tool arguments with zod schemas, and reaches out over HTTP with axios to a renderer.

Each tool is a thin wrapper. generate_bar_chart, generate_pie_chart, generate_radar_chart and the rest accept structured arguments and return a result. The rendering itself is not done locally by a charting library in the Node process; the README documents a VIS_REQUEST_SERVER environment variable and points at AntV's GPT-Vis-SSR project as an HTTP service you can deploy in a private environment. So the data flow is client to MCP server to render service to image. That indirection is the single most important design fact about this project, and it is also the thing most introductions skip.

Geographic tools behave differently. The README states that the geographic visualization tools use AMap service and currently only support map generation within China. generate_district_map, generate_path_map and generate_pin_map are therefore not general-purpose world maps.

Installing it and getting a first chart out of Claude or Cursor

The README gives the client configuration directly. On macOS, add this block to your MCP client config. The client launches npx, which downloads and runs the published package, so no global install is needed. After restarting the client, the chart tools should appear in its tool list.

{
  "mcpServers": {
    "mcp-server-chart": {
      "command": "npx",
      "args": ["-y", "@antv/mcp-server-chart"]
    }
  }
}

On Windows the command has to be routed through cmd, which the README shows explicitly:

{
  "mcpServers": {
    "mcp-server-chart": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@antv/mcp-server-chart"]
    }
  }
}

For a first real use, paste a small table into the chat and ask for a column chart of the values by category. The model should call generate_column_chart and return an image. If you want to run it as a network service instead of a stdio process, the docker-compose.yaml in the repository starts the same server over SSE:

docker compose up

The compose file builds the local Dockerfile, tags the image mcp-server-chart:stable, and runs node build/index.js --transport sse --port 1122 --host 0.0.0.0, publishing port 1122. The Dockerfile itself defaults to the streamable transport with CMD ["node", "build/index.js", "-t", "streamable"], so the compose command and the image default are not the same thing.

Where it breaks: remote rendering, China-only maps and no styling control

The default path sends your chart data to a remote render endpoint. If you are working with anything sensitive, that is a real constraint, and the README's answer is to self-host the renderer and point VIS_REQUEST_SERVER at it. The commented line in docker-compose.yaml shows the shape of that override: VIS_REQUEST_SERVER=http://127.0.0.1:3000/render, with a note that AntV's GPT-Vis-SSR can be deployed in a private environment. Setting that variable is a prerequisite for any private deployment, not an optional tweak.

The second limitation is geographic. Because the map tools use AMap, the README says they only support map generation within China. A team plotting European sales regions by district will not get usable output from generate_district_map.

The third is control. There are 26 tools and each one is a fixed chart type with its own argument schema. There is no documented theming layer, no way to hand the server a custom AntV spec, and no documented hook for your own color palette. You get the chart the tool draws. For exploratory analysis inside a chat that is fine. For a published report it usually is not, and you will end up exporting the data and rendering it yourself.

Alternatives and how their approach differs

The closest conceptual alternative is a diagram-as-code server such as a Graphviz MCP server. Graphviz does not try to be a general chart library; it takes a DOT graph description and lays out nodes and edges. If your real need is flowcharts, network graphs and dependency trees, a Graphviz-backed server gives you a text format you can version and diff, which antvis/mcp-server-chart does not expose.

Another route is a JavaScript charting library MCP server, for example one wrapping Chart.js or Highcharts. Those render inside the process with the library's own theming and plugin system, so you keep control over colors, axes and annotations. The trade-off runs the other way: antvis/mcp-server-chart covers a wider set of chart types out of the box, including sankey, violin, boxplot and word cloud, and it delegates rendering so the MCP process stays small. If you need a violin plot and do not want to write rendering code, that breadth is the reason to pick it. If you need your brand colors on every axis, the library-backed approach wins.

A third option is a hosted quick-chart image service. Those typically take a chart definition in a URL and return a PNG, with no MCP layer at all. You would then be writing the tool-calling glue yourself.

Maintenance, releases and licence

The repository is not archived, and the last push was on 2026-08-27. Recent published releases include 0.9.10 on 2026-02-25, 0.9.9 on 2026-01-22 and 0.9.7 on 2025-12-24. Note the gap between the last release and the last push: the code moves between publishes, so pinning a version rather than tracking the default branch is the safer choice for a client config.

Upgrade cost is low in the common case, because the client config resolves the package through npx and the tool surface is additive. The risk sits in argument schemas: if a tool's parameters change, the model's generated call can fail silently at the MCP layer. The package declares engines.node >=18, so an old Node runtime is a concrete upgrade blocker.

The licence is MIT, which permits commercial use and modification. The practical caveat is not the licence of the server but the terms of the render endpoint and of AMap for the geographic tools. If you self-host GPT-Vis-SSR, you are responsible for that service. This is a description of what the files state, not legal advice.

Editorial conclusion

Adopt it if you already drive an MCP client such as Claude, Cursor or Cline and want chart images back from a table without writing rendering code, and if your data is not China-only geographic. Skip it if you need full control over chart styling, if you need maps outside China, or if you cannot send data to a remote render endpoint. Before rolling it out, check whether the default render service is acceptable for your data, and confirm the DISABLED_TOOLS and VIS_REQUEST_SERVER settings in your client config.

Frequently asked questions

Official sources

1. antvis/mcp-server-chart on GitHub
2. License: MIT
3. Project website
4. README
5. Releases