mcp-dashboards
Related Servers
Alternatives to mcp-dashboards
- AlicenseNot gradedqualityDmaintenanceMCP server that captures TradingView chart images via Selenium — supports any ticker/interval with browser pooling for concurrent performance100MIT
- AlicenseAqualityBmaintenanceMCP server for the Trading 212 API. Provides 28 tools for portfolio management, trading, pies, dividends, market data, and analytics.2878 PyPI8MIT
Related Servers
- AlicenseNot gradedqualityBmaintenanceEnables agents to turn structured tabular data or CSV/XLSX files into interactive charts that render inline in conversations, with client-adaptive output modes and self-contained HTML.MIT
- FlicenseNot gradedqualityCmaintenanceEnables AI assistants to render interactive charts as generative UI inline in chat, including bars, lines, areas, donuts, tooltips, table views, and built-in series analysis.-
- AlicenseNot gradedqualityBmaintenanceLet AI agents create interactive visualizations that render live inside your chat — no code required.1BSD 3-Clause
- AlicenseAqualityDmaintenanceEnables AI agents to generate and render charts as PNG, SVG, or WebP images directly in chat interfaces. Supports Chart.js specifications and natural language descriptions for creating visualizations from data.34 npm1MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to create interactive charts, diagrams, and tables displayed on a real-time dashboard, supporting multiple data sources with privacy-focused local execution.1MIT
- FlicenseNot gradedqualityBmaintenanceRenders charts and diagrams as live interactive UI inside the chat, supporting ECharts for charts and Cytoscape for diagrams with streaming partial updates.-
TDQS
Scored across 40 tools
Most tools map to a clearly distinct chart type (pie, scatter, funnel, sankey, heatmap, etc.) and descriptions even frame each with a unique question like 'Where do we lose people?', which aids selection. There is some overlap among comparison-oriented charts (bar vs lollipop vs bullet vs waffle) and between render_from_json/render_from_url and the explicit renderers, but boundaries remain workable.
A strong render_<thing> prefix dominates the set, with file ops consistently using verb_noun (list_chart_files, delete_chart_files, save_file) and poll_http fitting the pattern. Minor deviation: some renders carry a _chart suffix while others (render_table, render_flowchart, render_dashboard, render_radial_cluster, render_bubble_map) do not, but the convention is still predictable.
40 tools is heavy for any server and sits in the 'too many' range. The breadth is partly justified since each chart type is a genuinely distinct visualization, but the surface feels large and could likely be consolidated (e.g. catalog tools, sparkline vs dashboard KPI cards).
Coverage is broad: dozens of chart types, a dashboard compositor, auto-detection from JSON/URL, live polling, discovery catalogs, and temp-file lifecycle management (list/delete). Minor gaps exist, such as export being app-only (save_file not AI-invocable) and no AI-facing way to edit or re-export a rendered chart.