antvis/mcp-server-chart：讓 LLM 直接畫出 26 種圖表，但地理圖表有中國限制

它解決的是 LLM 與圖表之間的格式鴻溝

大型語言模型擅長生成 JSON 或程式碼，但直接輸出 SVG 或 Canvas 往往結構鬆散，難以與既有前端框架整合。antvis/mcp-server-chart 把圖表生成包裝成 MCP 工具，每個工具對應一種 AntV 圖表類型，模型只要呼叫工具並傳入資料與欄位對應，就能得到結構化的圖表規格。這個專案服務的對象是使用 Claude Desktop、VSCode、Cline、Cursor 或 Dify 的開發者與資料分析師，他們希望讓 LLM 在對話中直接產出視覺化，而不是先寫一段 Python 再貼圖。它不負責渲染，渲染工作落在用戶端或使用者自己的應用程式上，這是理解整個專案的關鍵。

26 種工具背後的設計邏輯：以圖表意圖為單位

README 列出 26 個 generate_ 開頭的工具，從常見的 generate_bar_chart、generate_line_chart 到特殊的 generate_fishbone_diagram、generate_network_graph、generate_violin_chart。每個工具的描述都直接寫明適用情境，例如 generate_column_chart 用於垂直比較，generate_histogram_chart 用於區間計數。這種以圖表意圖為單位而非以底層 API 為單位的設計，讓 LLM 更容易選擇正確的工具，因為工具名稱與描述本身就是語意提示。相較於只提供一個 generate_chart 工具並要求模型自行填 type 參數的做法，這個專案把選擇責任部分轉移到工具清單上，代價是模型需要瀏覽更多工具定義，可能增加 token 消耗。

從 npx 到私有部署：實際啟動方式與環境變數

在 Mac 上，使用者只需在 MCP 用戶端設定檔中加入 command: npx 與 args: [-y, @antv/mcp-server-chart]。Windows 則改用 cmd /c npx。這表示它是一個可直接從 npm 執行的套件，不需要預先安裝。README 提到可以透過 SSE 或 Streamable transport 執行，但沒有提供具體的啟動指令，這點文件略顯不足。環境變數方面，VIS_REQUEST_SERVER 與 SERVICE_ID 分別對應私有部署與生成記錄功能，DISABLED_TOOLS 則用於工具過濾。這些變數的實際格式與範例在清理後的 README 中沒有揭露，使用者需要查閱原始文件或原始碼才能得知，這是採用前必須先確認的細節。

地理圖表的致命限制：AMap 服務只涵蓋中國

README 明確標註：地理視覺化工具（generate_district_map、generate_path_map、generate_pin_map）使用 AMap 服務，目前只支援中國境內地圖。這對非中國使用者是直接排除條款。如果你的資料不是中國行政區或 POI，這些工具會產生無效或錯誤的地圖。即使是中國使用者，也需注意 AMap 的服務條款與配額，因為 README 沒有說明是否需要 API key，或是否內建免費額度。這個限制讓地理圖表工具成為專案中最具地域性的部分，其他圖表類型則不受影響。若你的需求是跨國地圖，這個 server 不是正確選擇，你應該尋找使用 Leaflet 或 Mapbox 的 MCP。

生成記錄與工具過濾：企業部署的兩個把關機制

README 的目錄顯示有 Generate Records 與 Tool Filtering 兩節，分別對應 SERVICE_ID 與 DISABLED_TOOLS 環境變數。生成記錄功能可能用於稽核或重現 LLM 產生的圖表請求，這在需要追蹤模型行為的企業環境中有價值。工具過濾則讓管理者停用不需要的圖表類型，例如只開放 generate_bar_chart 與 generate_line_chart，避免模型誤用複雜的 generate_sankey_chart。這兩個機制顯示專案不是只為個人實驗設計，而是考慮了受管環境的需求。但 README 沒有提供實際的變數值範例，例如 DISABLED_TOOLS 是逗號分隔還是 JSON 陣列，這點文件品質有待改進。

與其他 MCP 視覺化方案的差異：AntV 生態的取捨

市場上其他 MCP 圖表 server 通常直接輸出 ECharts 或 Plotly 的規格，例如 echarts-mcp-server。antvis/mcp-server-chart 的差異在於它綁定 AntV 生態，這意味著輸出規格是 G2 或 G6 的語法，而非 ECharts 的 option 物件。如果你的前端已經使用 AntV 系列（G2Plot、G6、L7），那麼這個 server 的輸出可以直接餵給現有渲染元件，整合成本低。若你的團隊使用 ECharts，則需要額外撰寫轉換層，這會抵消 MCP 帶來的便利。另外，AntV 的文件與社群規模在國際上小於 ECharts，遇到問題時能找的資源較少，這是實際的維護成本。

維護與升級成本：以 npm 套件形式持續更新

專案以 MIT 授權釋出，最後一次 push 是 2026 年 8 月，近期釋出 0.9.10、0.9.9 與 0.9.7，顯示維護節奏穩定。因為它是 npm 套件，升級路徑就是更新版本號，但 MCP server 的介面變動（工具名稱或參數調整）可能破壞既有用戶端設定。0.9.x 系列仍在 minor version，代表 API 尚未穩定，採用時應鎖定版本而非使用 latest。README 的 build 徽章與 codecov 徽章顯示有自動化測試與覆蓋率追蹤，這對一個工具眾多的專案是正面訊號。但沒有看到遷移指南或 changelog 的連結，升級前需自行比對版本差異。

編輯結論

antvis/mcp-server-chart 適合已經在使用 Claude、Cline 或 Dify 等 MCP 用戶端，且需要快速產生標準商業圖表的團隊。它不適合需要地圖功能且使用者不在中國的場景，因為 AMap 服務只支援中國境內地圖。也不適合需要精細客製視覺編碼的資料分析，因為工具輸出的是 AntV 規格，而非靜態圖片，你必須自行渲染。採用前應先確認你的用戶端是否支援 MCP 的 Streamable transport，並檢查 DISABLED_TOOLS 是否能滿足你過濾工具的需求。若你的團隊已熟悉 ECharts，則應評估 ECharts MCP 的輸出格式是否更貼近現有前端棧，而不是直接選擇這個以 AntV 為核心的 server。

官方來源

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