AntV mcp-server-chart turns a language model into a chart renderer

One tool per chart type, twenty six of them

The design decision that shapes everything else is granularity. Instead of exposing a single render function with a type parameter, mcp-server-chart registers one MCP tool per output: `generate_column_chart`, `generate_sankey_chart`, `generate_venn_chart`, `generate_word_cloud_chart`. The count sits at 26 or more, and the list mixes statistical marks (boxplot, violin, histogram) with structural diagrams (fishbone, mind map, organization chart, flow diagram).

For the agent this matters, because tool names are the only thing the model reliably uses when choosing. A model asked to show retention by cohort will reach for `generate_column_chart` without being told the vocabulary. The cost is a fat tool list. Every conversation carries 26 schemas, and a schema-heavy list burns context even when the model only wants three of them.

One tool is not a plain chart. `generate_spreadsheet` reads a `rows` or `values` field and switches between a regular table and a pivot table, so the caller describes the shape of the data and the tool decides the rendering.

The geographic tools are the one place data leaves the machine

Three tools depend on an external map service. `generate_district_map`, `generate_path_map` and `generate_pin_map` call AMap, and the README carries a note that these support map generation within China only. That single sentence removes most of the non Chinese use cases for those three tools and puts an external service between the agent and the map, with whatever request behaviour AMap has.

If your evaluation data cannot be sent to a third party, the answer is not to argue about the remaining tools. The README documents a `DISABLED_TOOLS` environment variable under tool filtering, which is the intended place to cut the list down. That variable is the project's own answer to both the context cost and the data residency problem, and it is worth setting before the first conversation rather than after the first incident.

Three transports, and the one the Docker image actually starts

The package entry point is `build/index.js`, exposed as the `mcp-server-chart` bin, and a transport flag chooses between `sse` and `streamable`. The Dockerfile ships with streamable as its default command. The compose file in the repository overrides that, binds the server to all interfaces on port 1122 and maps the same port out. Starting the compose file as it ships therefore gives you an SSE endpoint reachable from the host, not the behaviour baked into the image.

Read both files together and the deployment story is clear. Node 18 or newer is the floor, stated in `engines`. Dependencies are small and ordinary: the MCP SDK, axios, cors, express and zod. There is no database and no queue, so a restart loses nothing but in flight renders.

Wiring it into a desktop client takes one JSON block

For a local client the whole install is an npx invocation, no global install and no clone. On macOS the config runs the package directly:

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

On Windows the same entry needs a shell wrapper, which the README gives explicitly:

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

Both blocks spawn the server over stdio, so nothing listens on a port and there is nothing to firewall. The first request will download the package, which is why `-y` is there. Hosts that speak HTTP or SSE, including the Dify plugin and the hosted listings the README points at, take the remote path instead.

A separate skill repo sits beside the server

The skill is not part of this package. The README points at `antvis/chart-visualization-skills` and installs it through a separate command:

npx skills add antvis/chart-visualization-skills

That split is worth understanding before you evaluate. The server is a fixed tool surface: it will generate a column chart when asked for a column chart. The skill is the part that picks the chart type, and it lives in another repository with its own release cycle. An agent with skill support can choose from the chart types on your behalf; a plain MCP client gets whatever the user typed.

So two demos of this project can look completely different while running the same server. Judge the skill separately if you are planning to rely on it, because upgrading the server does not upgrade the chart selection logic.

Private rendering means running GPT-Vis-SSR yourself

`VIS_REQUEST_SERVER` redirects rendering to an HTTP endpoint you control, and the README ties it to deploying AntV's GPT Vis SSR service in your own environment and passing that URL through the variable. The compose file carries the same idea as a commented environment line pointing at a local port 3000 render path.

That is the project's answer to organisations that cannot send chart payloads to a hosted renderer, and it is also the largest piece of work in adopting it, since the SSR service is a separate deployment. Anyone assuming the Docker image alone satisfies an air gapped requirement will find out otherwise. The README also lists `SERVICE_ID` under generate records.

Where this is the wrong tool

The output is an image produced by a fixed AntV specification, and that is the limit that decides adoption. A chart with a custom annotation, a brand typeface, a house colour ramp or a precise axis range cannot be expressed by choosing a different tool name.

Charts that ship in a product point one way. Charts an assistant produces during a conversation point the other. The maintenance record is recent enough to treat the project as current, with the last push on 2026-08-27 and version 0.9.11 in `package.json`, and an MIT licence that carries no restriction on commercial use.

Editorial conclusion

Adopt it if your assistant already speaks MCP and you want charts as tool output instead of code the user has to run, and if the fixed AntV visual language is acceptable to you. Check the full tool schemas before adopting it if you need control over annotations, fonts or colour ramps, and avoid the map tools if your data cannot reach an external service, because they call AMap. Verify two things before anything else: that your client renders the returned image rather than dumping a file path, and that DISABLED_TOOLS can trim the tool list down to the chart types you actually want in the model's context.

Frequently asked questions

Official sources

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