Modell / Datensatz
antvis/mcp-server-chart avatar
antvis/mcp-server-chart

antvis/mcp-server-chart: 26 Diagramm-Tools als MCP-Server für Claude, Cursor und Cline

🤖 A visualization mcp & skills contains 25+ visual charts using @antvis. Using for chart generation and data analysis.

4.364 Sterne418 ForksTypeScriptMIT

Auf einen Blick

Was ist das?
Der Server verpackt die AntV-Visualisierungsbibliotheken in MCP-Tools, die ein LLM direkt aufrufen kann. Der Ansatz ist praktisch für schnelle Diagramme aus Chatdaten, hat aber einen harten China-Zwang bei allen Karten und eine undokumentierte Serverabhängigkeit im Hintergrund.
Für wen ist es gedacht?
Wer Diagramme direkt aus einem Chat mit Claude, Cursor oder Cline braucht und keine Geodaten außerhalb Chinas verarbeitet, bekommt mit einem npx-Aufruf und einem JSON-Block in der MCP-Konfiguration einen funktionierenden Server. Wer Karten für Europa oder Nordamerika braucht, sollte vorher einen anderen Weg suchen, weil die geografischen Tools laut README ausschließlich den AMap-Dienst nutzen und auf China beschränkt sind.
Darf ich es kommerziell nutzen?
Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
Wird es noch gepflegt?
Ja. Die letzten Commits kamen vor 20 Tagen.
In welcher Sprache ist es geschrieben?
Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Welches Problem der Server löst und für wen er gedacht ist

Ein Sprachmodell kann Zahlen beschreiben, aber kein Diagramm zeichnen. Der übliche Workaround besteht darin, dass das Modell Code für eine Plot-Bibliothek ausgibt, den ein Mensch kopiert, ausführt und das Ergebnis irgendwo ablegt. antvis/mcp-server-chart schließt diese Lücke, indem es Diagrammerzeugung als MCP-Tools bereitstellt. Das Modell ruft ein Tool wie generate_bar_chart mit den Daten auf und erhält ein fertiges Bild zurück, ohne dass Zwischencode entsteht.

Die Zielgruppe sind nach der Beschreibung des Repositories Anwender von Desktop-Clients wie Claude, VSCode, Cline, Cherry Studio und Cursor. Das README nennt außerdem Dify als Integrationsweg, wo der Server als Plugin unter dem Namen antv/visualization läuft. Wer regelmäßig Ad-hoc-Auswertungen in einem Chat erledigt und die Ergebnisse als Bild weitergeben will, ist der typische Nutzer. Für eine fest eingeplante Diagrammkomponente in einer Webanwendung ist der Server der falsche Baustein, weil er ein Modell im Aufrufpfad voraussetzt.

26 Tools und die Aufteilung nach Diagrammfamilie

Das README zählt 26 oder mehr Diagrammtypen auf, jeder als eigenes Tool. Die Aufteilung folgt dem Datenzweck, nicht einer Bibliotheksstruktur. Für Verläufe gibt es generate_line_chart und generate_area_chart, für Verteilungen generate_histogram_chart, generate_boxplot_chart und generate_violin_chart. Vergleiche zwischen Kategorien decken generate_bar_chart und generate_column_chart ab, wobei das README die horizontale beziehungsweise vertikale Ausrichtung als Unterschied nennt. Anteile lassen sich über generate_pie_chart, generate_funnel_chart und generate_liquid_chart darstellen.

Auffällig ist die Gruppe der nicht-numerischen Diagramme: generate_fishbone_diagram für Ursachenanalysen, generate_flow_diagram für Abläufe, generate_mind_map für Hierarchien, generate_organization_chart für Aufbauorganisation, generate_network_graph für Beziehungen zwischen Knoten und generate_venn_chart für Mengenbeziehungen. Dazu kommt generate_spreadsheet, das laut README dann als Pivot-Tabelle rendert, wenn die Felder rows oder values übergeben werden, andernfalls als normale Tabelle. Diese Bandbreite ist der eigentliche Unterschied zu einem reinen Chart-Tool: Ein Teil der Tools hat nichts mit Zahlen zu tun, sondern mit Struktur.

Wie der Aufruf tatsächlich abläuft

Der Server ist in TypeScript geschrieben und wird über npx gestartet. Das Modell sieht die Tools über das MCP-Protokoll und wählt eines davon aus. Es übergibt die Daten, die es aus dem Gesprächskontext extrahiert hat, und der Server erzeugt daraus eine Visualisierung. Das README beschreibt diesen Weg als Diagrammerzeugung und Datenanalyse über MCP-Tools, ohne den internen Renderpfad im Detail zu dokumentieren.

Eine Besonderheit ist im Abschnitt zu den Umgebungsvariablen sichtbar: VIS_REQUEST_SERVER existiert, und das README verknüpft diese Variable mit dem Thema Private Deployment. Daraus lässt sich schließen, dass der Server die eigentliche Zeichnung nicht zwingend lokal erledigt, sondern an einen Dienst schickt, der ersetzt werden kann. Der technische Aufbau dieser Schnittstelle wird im vorliegenden Material nicht beschrieben. Wer den Datenfluss vollständig kontrollieren muss, sollte diesen Punkt vor der Einführung klären, weil sonst unklar bleibt, wo die übergebenen Daten verarbeitet werden.

Für Mehrbenutzerbetrieb nennt das README zwei Transportwege. Neben dem Standardtransport über die Kommandozeile gibt es einen Abschnitt zu SSE oder Streamable transport. Welche Endpunkte dabei entstehen und wie die Authentifizierung aussieht, geht aus dem Auszug nicht hervor.

Installation in der MCP-Konfiguration

Die Einrichtung besteht aus einem Eintrag in der Konfigurationsdatei des Clients. Für macOS gibt das README diesen Block an:

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

Unter Windows wird der Aufruf über die Shell geleitet, weil npx dort nicht direkt als Kommando funktioniert:

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

Der Server läuft damit lokal als Prozess, den der Client startet und beendet. Ein separates Deployment ist für den Einzelplatz nicht nötig. Das Paket liegt unter dem Namen @antv/mcp-server-chart auf npm, die Lizenz ist MIT.

Drei Umgebungsvariablen mit sehr unterschiedlichem Gewicht

Das README dokumentiert genau drei Umgebungsvariablen, und sie betreffen drei verschiedene Probleme. VIS_REQUEST_SERVER ersetzt den Dienst, der die Visualisierung erzeugt. SERVICE_ID dient laut README der Erzeugung von Aufzeichnungen, also einer Art Nutzungsprotokollierung. DISABLED_TOOLS filtert Tools heraus.

DISABLED_TOOLS ist die praktisch nützlichste der drei. Ein Modell, das 26 Werkzeuge zur Auswahl hat, wählt nicht immer das passende. Wer nur Linien- und Balkendiagramme braucht, kann den Rest abschalten und reduziert damit die Fehlauswahl. Das README beschreibt die Variable unter der Überschrift Tool Filtering, ohne das exakte Format der Liste anzugeben. Hier lohnt ein Blick in den Quellcode oder in die Paketdokumentation, bevor die Variable gesetzt wird.

SERVICE_ID ist der Punkt, an dem Datenschutz relevant wird. Wenn diese Kennung eine Zuordnung von Aufrufen ermöglicht, muss vor dem Einsatz geklärt sein, ob das gewünscht ist. Das README liefert dazu keine Angaben darüber, welche Daten wohin übertragen werden. Wer den Server in einem Unternehmenskontext einführt, sollte diesen Punkt nicht übergehen.

Die Kartenfunktionen sind auf China beschränkt

Das ist die deutlichste Einschränkung im gesamten Material. Der Server bietet generate_district_map, generate_path_map und generate_pin_map. Eine Notiz im README stellt klar, dass die geografischen Visualisierungstools den AMap-Dienst nutzen und derzeit nur Kartenerzeugung innerhalb Chinas unterstützen.

Für Anwender im deutschsprachigen Raum bedeutet das: Adressdaten aus Berlin, Wien oder Zürich lassen sich mit diesen drei Tools nicht darstellen. Alle anderen Diagrammtypen sind davon nicht betroffen, weil sie keine Geobasis benötigen. Wer den Server hauptsächlich wegen Karten einsetzen will, sollte ihn deshalb gar nicht erst in Betracht ziehen. Wer ihn wegen der übrigen 23 Tools einsetzt, kann die Kartenfunktionen über DISABLED_TOOLS abschalten, damit das Modell sie nicht fälschlich auswählt.

Ein zweiter Punkt: Die Kartenfunktionen hängen an einem externen Dienst. Fällt AMap aus oder ändert der Anbieter seine Bedingungen, betrifft das genau diese drei Tools. Die übrigen Diagramme laufen über den Renderpfad, der mit VIS_REQUEST_SERVER austauschbar ist.

Alternative: Diagramme als Code im Modell erzeugen lassen

Der naheliegende andere Weg ist, dem Modell beizubringen, Code für eine JavaScript-Diagrammbibliothek auszugeben, den der Anwender selbst ausführt. Der Unterschied liegt nicht in der Bildqualität, sondern im Kontrollpunkt. Beim Code-Weg entsteht ein Artefakt, das im Repository liegt, versioniert, getestet und in eine Anwendung eingebaut werden kann. Beim MCP-Weg entsteht ein Bild im Gesprächsverlauf.

Das ist ein echter Trade-off und keine Frage von besser oder schlechter. Der MCP-Server gewinnt, wenn jemand schnell eine Auswertung sehen will und kein Projekt dafür aufsetzen möchte. Der Code-Weg gewinnt, wenn das Diagramm reproduzierbar sein muss, wenn es in eine Pipeline gehört oder wenn die Daten das Haus nicht verlassen dürfen. Ein weiterer Unterschied: Beim Code-Weg bestimmt der Anwender die Bibliotheksversion und kann das Ergebnis ohne Modell erneut erzeugen. Beim MCP-Server hängt das Ergebnis von der Version des npm-Pakets ab, die npx beim Start zieht.

Wer bereits AntV in einer Anwendung nutzt, findet im Server keine neue Rendering-Engine, sondern eine andere Bedienoberfläche für dieselben Bibliotheken. Der Mehrwert liegt in der Anbindung an das Modell, nicht in der Grafik selbst.

Wartung, Versionen und Lizenz

Die letzten veröffentlichten Versionen sind 0.9.10 vom Februar 2026, davor 0.9.9 im Januar und 0.9.7 im Dezember 2025. Der Repository-Stand reicht bis August 2026. Die Versionsnummern bleiben in der 0.x-Reihe, was bedeutet, dass Schnittstellenänderungen ohne größeren Versionssprung möglich sind. Wer den Server produktiv einsetzt, sollte die Version in der MCP-Konfiguration festnageln statt npx ungepinnt aufzurufen. Das Argument -y in den Beispielen installiert ohne Rückfrage, was in einer kontrollierten Umgebung unerwünscht sein kann.

Die Lizenz ist MIT. Das ist die permissivste der gängigen Varianten und erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, solange der Lizenztext und der Urheberrechtshinweis beibehalten werden. Ein Punkt, der nicht in der Lizenz steht: Der Server stützt sich auf externe Dienste, namentlich AMap für Karten und den Renderdienst hinter VIS_REQUEST_SERVER. Deren Nutzungsbedingungen gelten zusätzlich und können sich unabhängig vom Code ändern. Eine rechtliche Bewertung ersetzt dieser Absatz nicht.

Der Wartungsaufwand hängt davon ab, wie viele der 26 Tools tatsächlich gebraucht werden. Wer nur fünf davon nutzt, trägt bei jedem Versionssprung nur ein kleines Risiko. Wer alle aktiv lässt, muss bei Änderungen an einzelnen Tool-Signaturen mit Fehlauswahlen durch das Modell rechnen.

Redaktionelles Fazit

Wer Diagramme direkt aus einem Chat mit Claude, Cursor oder Cline braucht und keine Geodaten außerhalb Chinas verarbeitet, bekommt mit einem npx-Aufruf und einem JSON-Block in der MCP-Konfiguration einen funktionierenden Server. Wer Karten für Europa oder Nordamerika braucht, sollte vorher einen anderen Weg suchen, weil die geografischen Tools laut README ausschließlich den AMap-Dienst nutzen und auf China beschränkt sind. Vor dem Produktiveinsatz ist zu klären, ob der Standard-Rendering-Endpunkt für die eigenen Daten in Frage kommt oder ob mit VIS_REQUEST_SERVER ein eigener Dienst betrieben werden muss.

Offizielle Quellen

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

Community-Notizen