mcp-server-chart を採用する前に確認したい、26 種類のチャート生成と AMap 依存の境界

誰のためのサーバーか、会話の中にグラフを差し込む用途

このプロジェクトが埋めるのは、LLM との会話の中にグラフ画像を出したいが、そのためにフロントエンドを書きたくないという隙間である。README は用途を「chart generation」と「data analysis」の 2 語で説明している。MCP クライアント側から見ると、モデルが generate_bar_chart や generate_pie_chart といったツールを呼び、その戻り値としてチャートが得られる。利用者はデータを表の形で渡し、軸や系列の指定をツール引数として書く。自分で可視化コードを書く代わりに、モデルに「これを棒グラフにして」と頼む操作が成立するわけだ。

想定読者は、Claude、VSCode、Cline、Cherry Studio、Cursor といったデスクトップアプリの MCP 設定を自分で編集できる層である。README はこれらを名指しして設定例を載せている。Dify のマーケットプレイスにもプラグインとして登録されていると書かれており、ノーコード寄りの利用経路も用意されている。逆に、可視化の細部を CSS やテーマで制御したい人、あるいは生成物をドキュメントに埋め込む前にベクター形式へ変換したい人には、このサーバーの抽象度は粗すぎる。

generate_* ツール一覧と、spreadsheet が表とピボットを兼ねる設計

README の Features 節には 26 個のツールが列挙されている。generate_area_chart、generate_bar_chart、generate_boxplot_chart、generate_column_chart、generate_district_map、generate_dual_axes_chart、generate_fishbone_diagram、generate_flow_diagram、generate_funnel_chart、generate_histogram_chart、generate_line_chart、generate_liquid_chart、generate_mind_map、generate_network_graph、generate_organization_chart、generate_path_map、generate_pie_chart、generate_pin_map、generate_radar_chart、generate_sankey_chart、generate_scatter_chart、generate_treemap_chart、generate_venn_chart、generate_violin_chart、generate_word_cloud_chart、generate_spreadsheet である。

このうち設計上おもしろいのは generate_spreadsheet だ。README によれば、引数に rows または values フィールドを渡すとピボットテーブル（クロス集計）として描画され、渡さなければ通常の表になる。つまりツール名は 1 つだが、引数の形でレンダリング経路が分岐する。モデルがどちらの意図で呼んだのかを引数の有無だけで判定する構造なので、集計のつもりが素の表になる、あるいはその逆の取り違えが起きうる。プロンプト側で rows や values を明示させる運用が要る。

チャート種別の幅は広い。統計系（boxplot、histogram、violin）、関係性（network、sankey、venn）、構造（mind_map、organization_chart、treemap）、因果（fishbone_diagram）、工程（flow_diagram）まで含む。ただし README は各ツールの引数スキーマを載せていないため、どのフィールド名でデータを渡すかはパッケージ側の定義を読むまで分からない。

地図系 3 ツールは AMap 依存で、中国国内に閉じている

README の注記ははっきりしている。地理可視化チャートの生成ツールは AMap サービスを利用しており、現時点では中国国内の地図生成のみをサポートする。該当するのは generate_district_map、generate_path_map、generate_pin_map の 3 つである。

これは単なる機能不足ではなく、アーキテクチャ上の依存を意味する。行政区画、経路、POI の描画は自前のジオメトリを持たず、外部サービスへ問い合わせて成立している。したがって中国国外の住所や座標を渡した場合の挙動は README からは読み取れない。エラーになるのか、空の地図が返るのか、中国国内の地図に外国の点が落ちるのか、記載がない。海外拠点のデータを扱うチームにとっては、この 3 ツールは事実上使えないものとして扱い、DISABLED_TOOLS で落とす前提で設計したほうがよい。

地図以外の 23 ツールは AMap に触れない。ここを分けて考えるのが、このサーバーを評価する際の第一歩になる。

導入は npx 一発、OS ごとに設定 JSON が変わる

README が示す最小構成は npx 経由である。Mac の場合、MCP クライアントの設定に次のように書く。

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

Windows では command を cmd にし、args の先頭に /c を足す形が示されている。

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

Windows でこの 1 行を省くと npx が起動しない。OS をまたいで同じ設定ファイルを共有しているチームは、ここで必ず一度つまずく。

CLI オプションと環境変数も用意されている。環境変数は VIS_REQUEST_SERVER、SERVICE_ID、DISABLED_TOOLS の 3 つが README の目次に現れる。VIS_REQUEST_SERVER は Private Deployment の節に対応し、SERVICE_ID は Generate Records、DISABLED_TOOLS は Tool Filtering に対応する。SSE または Streamable transport で動かす節も独立して用意されている。

DISABLED_TOOLS と VIS_REQUEST_SERVER が示す、公開サービス前提の構造

環境変数の並びは、このサーバーが何を外部に委ねているかを示している。VIS_REQUEST_SERVER は可視化リクエストの送り先を差し替える設定だ。Private Deployment という節名が付いていることから、既定では何らかのホスト型サービスへリクエストが飛び、自前のサーバーに切り替える余地が用意されていると読める。

ただし README からは、既定の送り先がどこなのか、そのサービスにデータがどう扱われるのかが分からない。渡した表データがサーバー側で保持されるのか、生成後に破棄されるのか、記載がない。業務データを扱うなら、ここは導入前に必ず確認すべき点である。VIS_REQUEST_SERVER で自前のエンドポイントに向ければ外部送信は避けられるが、その場合に何を立てればよいのかは README の範囲では不明だ。

SERVICE_ID は Generate Records の節に対応する。生成記録を識別するための値と読めるが、記録がどこに溜まるのかは明記されていない。DISABLED_TOOLS はツールのフィルタリングで、26 個のうち使わないものを落とす。地図系 3 ツールを外す、あるいはモデルのツール選択を狭めて誤呼び出しを減らす、といった用途が考えられる。ツール数が 26 もあると、モデルが適切なチャート種を選べずに外す場面が増えるため、この設定は実務上かなり効く。

データが手元で完結しないという制約

最大の制約は、チャート生成がローカルで完結するかどうかが README から確定できない点である。VIS_REQUEST_SERVER という設定の存在は、既定でリモートの可視化サービスに依存していることを強く示唆する。もしそうなら、顧客リストや売上明細をチャート化するたびに、そのデータが外部へ送られることになる。

これは「オフラインで動く MCP サーバー」という期待とは食い違う。MCP サーバーは stdio で手元のプロセスとして起動するため、ついローカル完結だと想定してしまう。しかし stdio で起動することと、処理がローカルで完結することは別の話だ。npx で立ち上がるプロセスが、リクエストを外部 API へ転送する構成は珍しくない。

もう 1 つの限界は出力形式である。README はチャートを「生成する」と書くが、返るのが PNG なのか URL なのか、MCP のレスポンスとして画像が埋め込まれるのかは明記されていない。後段でファイルに保存したり、PDF に貼ったりする処理を組むなら、この点が確定するまで設計に入れないほうがよい。

Vega-Lite 系ツールとの設計差、仕様を書くか委ねるか

比較対象として分かりやすいのは、Vega-Lite の仕様をそのまま出力させ、レンダリングは別のライブラリに任せるタイプの MCP サーバーである。あちらはモデルに JSON 仕様を書かせ、描画はクライアント側で行う。出力はテキストなので、差分を取れる、Git で管理できる、後から手で微修正できる。

mcp-server-chart は逆を行く。モデルはチャート種別とデータだけを渡し、描画の詳細は AntV 側の実装に委ねる。利点は、モデルが座標計算やスケール調整で失敗しないこと。26 種類のチャートそれぞれに引数の形が決まっているので、モデルが選ぶのは「どのツールを呼ぶか」と「どのフィールドに何を入れるか」だけで済む。欠点は、生成物が不透明な点だ。色や軸ラベルを 1 箇所だけ直したいと思っても、仕様が手元に残らないため、プロンプトを書き換えて再生成するしかない。

どちらが優れているという話ではない。会話の中で使い捨てのグラフを出すなら mcp-server-chart、レポートに載せる図を版管理しながら育てるなら仕様出力型、という住み分けになる。

MIT ライセンスと、更新頻度から見た保守コスト

ライセンスは MIT である。npm パッケージ @antv/mcp-server-chart のライセンス表記も MIT と一致している。商用利用を含めて制約は緩い。ただし、このサーバーが依存する AMap サービスや既定の可視化サービスの利用条件は MIT の範囲外であり、別途確認が必要になる。地図系ツールを使うなら AMap 側の規約が、VIS_REQUEST_SERVER を既定のまま使うなら送り先サービスの規約が、それぞれ適用される。ここは法的判断ではなく、単に確認先が 2 つあるという話である。

保守の観点では、リリース間隔が参考になる。0.9.7 が 2025 年 12 月 24 日、0.9.9 が 2026 年 1 月 22 日、0.9.10 が 2026 年 2 月 25 日。約 1 か月ごとにパッチが当たっている。0.9 系が続いており、1.0 には達していない。マイナーバージョンが 0 の間は、ツールの引数スキーマが予告なく変わりうると考えておいたほうがよい。npx で最新を引く設定は手軽だが、ある日モデルの呼び出しが通らなくなるリスクを抱える。バージョンを固定するか、更新時にツール一覧を確認する手順を決めておくべきだ。

リポジトリはアーカイブされておらず、最終 push は 2026 年 8 月 27 日となっている。

編集部の結論

チャット UI やノートアプリの中で、表データを貼って棒グラフや円グラフの画像をその場で出したい人には向いている。逆に、データを外部サービスへ送れない環境、地図チャートを中国国外で使いたい用途、SVG やベクター形式の出力を後段の処理に流したいパイプラインには向かない。導入前に確認すべきは 3 点で、第一に地図系 3 ツール（generate_district_map、generate_path_map、generate_pin_map）が AMap に依存し中国国内のみ対応という README の注記、第二に VIS_REQUEST_SERVER を設定しない場合のリクエスト先が README からは判別できないこと、第三に生成画像がどの形式で返るのかが README に明記されていないことだ。この 3 点を自分の環境で確かめてから、DISABLED_TOOLS で不要なツールを絞る設定に進むのが順当である。

公式情報源

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