mcp-server-chart : un serveur MCP qui produit 26 types de graphiques AntV

Le problème : un assistant qui décrit un graphique au lieu de le dessiner

Un modèle de langage sait écrire la phrase « tracez un histogramme de ces valeurs » sans jamais produire d'image. Le projet antvis/mcp-server-chart comble cet écart en exposant la bibliothèque AntV sous forme d'outils MCP. Le README présente l'objectif en deux mots : chart generation et data analysis. Concrètement, l'assistant n'a plus à inventer une syntaxe de rendu, il appelle un outil nommé et reçoit un graphique.

Le public visé est celui qui travaille déjà dans un client compatible MCP : Claude, VSCode, Cline, Cherry Studio, Cursor, ou encore Dify via le plugin visualization publié sur le marketplace Dify. Ce n'est pas une bibliothèque que l'on importe dans une application métier. C'est un processus Node lancé à côté du client, qui parle le protocole MCP. Si vous cherchez un composant React à intégrer dans un tableau de bord, vous êtes au mauvais endroit.

Le catalogue annoncé est large : 26 graphiques et plus selon le README. On y trouve les classiques (bar, column, line, pie, scatter, radar), des formes statistiques (boxplot, histogram, violin), des diagrammes relationnels (sankey, network, venn), des schémas structurés (fishbone, flow, mind-map, organization) et trois outils cartographiques. Dernier ajout notable, generate_spreadsheet : sans champs rows ou values il rend un tableau simple, avec eux il bascule en tableau croisé dynamique.

Comment un appel d'outil devient une image

Le dépôt est en TypeScript et le paquet publié s'appelle @antv/mcp-server-chart. Le diagramme technique du README montre un serveur qui reçoit une requête MCP, la transforme en spécification de rendu AntV, puis renvoie un résultat au client. Le README ne détaille pas le format exact de la réponse, ni si l'image revient en base64, en URL ou en identifiant de ressource. C'est une zone d'ombre que je signale plutôt que de la combler par supposition.

Ce qui est documenté, en revanche, c'est le levier de configuration. La variable VIS_REQUEST_SERVER permet de rediriger les demandes de génération vers un serveur de votre choix. Le README consacre une section intitulée Private Deployment à ce point. C'est le mécanisme central à comprendre : par défaut, le serveur s'appuie sur une infrastructure de génération distante, et cette variable existe précisément pour la remplacer.

Deuxième variable, SERVICE_ID, rattachée à une section Generate Records. Le README la présente comme un identifiant de service utilisé pour l'enregistrement des générations. Autrement dit, si vous laissez la valeur par défaut, vos appels peuvent être comptabilisés côté service distant. Pour un usage en entreprise, ce n'est pas un détail cosmétique.

Troisième variable, DISABLED_TOOLS, qui filtre les outils exposés. Le README y consacre une section Tool Filtering. L'intérêt est direct : un client MCP qui reçoit 26 définitions d'outils consomme du contexte dans la fenêtre du modèle. Restreindre la liste aux cinq ou six graphiques réellement utiles est une décision de conception, pas un réglage mineur.

Mise en route : deux blocs JSON et une variable à surveiller

L'installation passe par npx, sans installation globale. Le README donne le bloc pour macOS :

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

Sous Windows, la commande change, car npx doit être invoqué via cmd :

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

Le README mentionne également un mode SSE ou Streamable transport, avec une section dédiée, ainsi qu'une section CLI Options. Le contenu de ces deux sections n'apparaît pas dans l'extrait fourni : je ne peux donc pas citer de drapeau précis. Si vous comptez héberger le serveur pour une équipe plutôt que de le lancer en local, il faudra consulter ces pages du dépôt avant de dimensionner quoi que ce soit.

Pour un déploiement privé, l'étape suivante consiste à définir VIS_REQUEST_SERVER dans l'environnement du processus MCP, en pointant vers votre propre instance de génération. Tant que cette variable n'est pas positionnée, vous dépendez de l'endpoint par défaut. C'est la première chose à vérifier dans un contexte où les données ne doivent pas sortir.

Enfin, le README renvoie à la page npm du paquet pour la version et la licence, et à la page Dify pour l'usage via ce marketplace. Le dépôt est publié sous licence MIT.

Les cartes : une dépendance externe et une limite géographique assumée

C'est la contrainte la plus concrète du projet, et elle est écrite noir sur blanc dans un encadré du README : les outils de visualisation géographique utilisent le service AMap et ne prennent en charge que la génération de cartes à l'intérieur de la Chine. Cela concerne generate_district_map, generate_pin_map et generate_path_map.

Les conséquences sont doubles. D'abord une dépendance à un fournisseur tiers, avec les questions habituelles de quota, de clé et de disponibilité. Ensuite une couverture géographique fermée. Une équipe qui veut cartographier des points de vente en Europe ou des livraisons au Brésil n'obtiendra rien de ces trois outils. Aucune option de bascule vers un autre fournisseur de tuiles n'est décrite dans le matériel fourni.

Il y a un second point que le README n'aborde pas : les données envoyées à un service de géocodage ou de rendu cartographique sortent de votre périmètre. Pour des adresses clients, c'est une question à trancher avant la mise en production, pas après.

Le reste du catalogue, en revanche, ne dépend pas d'AMap. Un histogramme, un sankey ou un diagramme de flux sont des rendus déterministes à partir de données tabulaires. C'est là que le projet est le plus confortable.

Ce que le serveur ne fera pas à votre place

Un serveur de rendu ne juge pas la pertinence du graphique. Si l'assistant choisit generate_pie_chart pour comparer douze catégories, vous obtiendrez un camembert illisible, correctement dessiné. Le README décrit chaque outil avec sa vocation, mais rien n'indique qu'un contrôle soit exercé sur le nombre de catégories, les échelles ou les unités. La qualité du résultat dépend donc de la qualité de la consigne donnée au modèle.

Deuxième limite : le projet est un serveur, pas un pipeline de données. Il ne va pas chercher vos données, ne les nettoie pas, ne les agrège pas. Vous devez fournir des séries déjà propres. Un generate_dual_axes_chart avec deux variables d'unités différentes ne vous avertira pas si vous avez inversé les axes.

Troisième point, plus terre à terre : le paquet est distribué via npx avec le drapeau -y, ce qui télécharge et exécute la version courante sans confirmation. Pour un poste de développeur, c'est pratique. Pour un parc de machines en entreprise, c'est un choix à assumer explicitement, et il vaut mieux épingler une version précise dans les args plutôt que de laisser npx résoudre la dernière publiée.

Enfin, le projet n'est pas archivé et le dernier push indiqué est le 27 août 2026, avec des publications régulières entre décembre 2025 et février 2026. Le rythme de publication suggère un projet actif, mais cela ne dit rien de la stabilité de l'API des outils d'une version à l'autre.

Face à quoi on le compare réellement

L'alternative la plus directe n'est pas un autre serveur MCP, c'est l'absence de serveur MCP. Un assistant peut produire du code Vega-Lite, du Mermaid ou une configuration ECharts que vous exécutez vous-même. La différence d'approche est nette : avec mcp-server-chart, le rendu est délégué à un processus AntV et le modèle n'a qu'à choisir un outil et passer des données. Avec la génération de code, le modèle écrit une spécification que votre environnement exécute, ce qui vous laisse le contrôle total du rendu, du thème et de l'hébergement, au prix d'une étape d'exécution à maintenir et d'un risque d'erreur de syntaxe plus élevé.

Le choix dépend donc de qui doit porter la responsabilité du rendu. Si vous voulez un graphique immédiat dans la conversation, sans écrire de code, le serveur MCP est plus court. Si vous devez intégrer le graphique dans une application existante avec votre charte graphique, la génération de code ou une bibliothèque appelée directement reste plus prévisible.

Sur le terrain des diagrammes non statistiques, mind-map, flow et fishbone, la comparaison se fait avec Mermaid, qui produit du texte versionnable. Un diagramme Mermaid se relit dans une revue de code, se diffe de commit en commit. Un graphique généré par outil MCP est un artefact binaire ou une URL, beaucoup moins pratique à versionner. C'est un argument en faveur de Mermaid pour de la documentation technique, et en faveur de mcp-server-chart pour de l'exploration visuelle rapide.

Coût de maintenance et implications de licence

La licence est MIT, indiquée à la fois dans le README et dans les métadonnées du dépôt. Concrètement, cela autorise la réutilisation, la modification et la redistribution, y compris dans un produit commercial, à condition de conserver la notice de copyright et le texte de licence. Je ne donne pas d'avis juridique : pour un usage encadré, faites relire le fichier LICENSE du dépôt.

Un point mérite attention et ne relève pas de la licence du code : le service de génération par défaut et le service AMap pour les cartes sont des dépendances externes avec leurs propres conditions d'utilisation. La licence MIT du serveur ne couvre pas ces services. Si vous déployez en privé, vous remplacez le premier par votre propre instance via VIS_REQUEST_SERVER, mais les outils cartographiques continuent de reposer sur AMap.

En termes de maintenance, le coût principal est le suivi des versions du paquet et la compatibilité des définitions d'outils avec votre client MCP. Les publications listées vont de 0.9.7 en décembre 2025 à 0.9.10 en février 2026, ce qui reste dans une série 0.x : l'API n'est pas déclarée stable par le numéro de version. Un déploiement en équipe gagnerait à figer une version dans les args npx et à la faire évoluer par décision, pas par mise à jour automatique.

Conclusion éditoriale

Adoptez mcp-server-chart si vous voulez que Claude, Cursor, Cline ou Cherry Studio produise un diagramme à partir de données déjà structurées, et si vos visuels ne dépendent pas d'une carte chinoise. Écartez-le si vos données sont confidentielles et que vous refusez de pointer VIS_REQUEST_SERVER vers un service que vous contrôlez, ou si votre cas d'usage repose sur generate_pin_map, generate_path_map ou generate_district_map hors de Chine. Avant d'installer, vérifiez dans votre registre npm la version publiée de @antv/mcp-server-chart, puis fixez VIS_REQUEST_SERVER et SERVICE_ID dans la configuration du client MCP.

Sources officielles

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