Skip to main content
Glama
liminalpepe

x402-dataviz-mcp

by liminalpepe
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

x402-dataviz-mcp

A free MCP (Model Context Protocol) server that renders bar, line, and area charts from structured data and returns clean, hand-designed SVG. No API key, no payment, no rate limit games — just an MCP tool any MCP client can call.

This is the open funnel twin of a paid, x402-gated HTTP API:

x402-dataviz-poc.theliminalguy.workers.dev — POST /chart, $0.01 USDC on Base per call via the x402 payment protocol, for production/high-volume or non-MCP (plain HTTP) use. Same renderer, same output, just billed per call instead of free-via-MCP.

Why this exists

The x402 Bazaar (~14,800 agent-payable APIs at time of writing) has zero coverage in "structured data → clean chart image." This MCP server is the free/local half of filling that gap — try it for nothing via MCP; reach for the paid HTTP endpoint when you need it at volume or outside an MCP client.

Related MCP server: PlotMCP Server

What it does

One tool, render_chart, takes a chart type + structured data points and returns a rendered SVG string. Rendering is hand-rolled (no headless browser, no native binaries, no heavy charting framework) — just string-built SVG, so it's fast with zero runtime dependency risk.

The design bar is the actual differentiator: a real categorical color palette (validated for colorblind-safety, not eyeballed), considered spacing, thin marks with rounded bar ends, 2px surface gaps between bars, ringed line markers, direct end-labels, and full light/dark theme support — not the default-blue/red/green look of a generic charting library.

Install & run

npx x402-dataviz-mcp

Or add it to an MCP client config (e.g. Claude Desktop's claude_desktop_config.json):

{
  "mcpServers": {
    "dataviz": {
      "command": "npx",
      "args": ["-y", "x402-dataviz-mcp"]
    }
  }
}

Tool: render_chart

Input:

{
  "type": "bar" | "line" | "area",
  "title": "optional string",
  "theme": "light" | "dark",       // defaults to "light"
  "data": [
    { "x": "Q1", "values": { "Revenue": 128000, "Cost": 84000 } },
    { "x": "Q2", "values": { "Revenue": 146500, "Cost": 91200 } }
  ]
}

values can hold one or more named series; series colors are assigned from a fixed, colorblind-validated order (never generated/cycled). A legend renders automatically for 2+ series; a single series needs no legend (the title already names it).

Output: an SVG string (as MCP tool text content) rendering the requested chart.

Local development

npm install
npm run dev      # runs src/index.ts directly on stdio via tsx
npm run build    # compiles to dist/ for the published npm package

When to use the paid HTTP twin instead

Use POST /chart on the paid Worker instead of this MCP server when:

  • You're calling from outside an MCP client (plain HTTP, any language).

  • You need production/high-volume use and want to pay per call rather than rely on a free tool being available indefinitely.

  • Your agent already speaks x402 (e.g. via x402-fetch / x402-axios) and can pay $0.01 USDC on Base per request.

Both routes call the exact same renderChart() function — output is byte-for-byte identical.

License

MIT

Available Tools

1 tool
render_chartRender ChartA

Render a bar, line, or area chart from structured data and return it as an SVG string. Free, unauthenticated MCP tool — the open twin of the paid x402-gated dataviz HTTP API (https://x402-dataviz-poc.theliminalguy.workers.dev/chart), same renderer, no payment required.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesNon-empty array of data points
typeYesChart type: bar, line, or area
themeNoOptional theme, defaults to "light"
titleNoOptional chart title

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool is 'Free, unauthenticated,' returns an 'SVG string,' and is 'the same renderer' as the paid API. This gives critical behavioral context (auth, cost, output format) beyond the schema. It doesn't detail error handling or side effects, but for a pure chart-rendering tool, this is substantial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core function, and every word serves a purpose. It includes the key output format, cost, authentication status, and alternative context without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (4 params, 100% schema coverage, no output schema), the description is complete: it states the purpose, output format, auth requirements, and distinguishes from the paid API. It doesn't need to explain return values beyond the SVG string since that's the output. No critical gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description doesn't add parameter-specific details beyond what the schema already provides; it merely references 'structured data' and chart types, which are already documented in the schema. It adds no extra semantic value for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Render'), resource ('chart'), and output ('SVG string'). It also distinguishes itself from the paid HTTP API by positioning as the free twin, effectively differentiating it from an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly names an alternative (the paid x402-gated API) and positions this free MCP tool as the recommended option, saying 'no payment required.' It implies when to use it (when you need chart rendering without cost), though it doesn't explicitly list when not to use it. This is clear contextual guidance, but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedrender_chart
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool in the server, there is zero possibility of confusing it with another tool. The purpose of the tool is clearly described, covering bar, line, and area charts.

Naming Consistency5/5

The single tool name 'render_chart' follows a clean verb_noun pattern. With only one tool, naming consistency is trivially achieved.

Tool Count3/5

The server contains exactly one tool, which feels thin for a typical MCP server. However, the scope is narrow (chart rendering), so the single tool is not entirely unreasonable, but it is borderline.

Completeness3/5

The tool covers the core function of rendering a chart, but lacks auxiliary operations such as data validation, chart configuration, or output handling. For a focused dataviz server, this may suffice but leaves some gaps for more complex workflows.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • mcp-plots

    MR901
    A
    license
    A
    quality
    D
    maintenance
    A MCP server for data visualization. It exposes tools to render charts (line, bar, pie, scatter, heatmap, etc.) from data and returns plots as either image/text/mermaid diagram.
    2
    4
    MIT

  • PlotMCP Server

    Nexo-Agent
    F
    license
    A
    quality
    D
    maintenance
    An MCP server that enables LLMs to generate high-quality SVG charts using matplotlib, supporting various plot types like line, bar, and heatmaps. It provides flexible configuration for dimensions and axis scales, returning either raw SVG content or paths to saved image files.
    9
    -

  • vvk-charts-mcp

    valderan
    A
    license
    A
    quality
    D
    maintenance
    A modern Python MCP server for rendering customizable charts (line, bar, pie, scatter, area, combined dashboards) with Plotly, supporting export to PNG, SVG, and base64, and terminal charts with ANSI output.
    9
    1
    MIT

  • mcp-chart-forge

    joconnell19
    F
    license
    Not graded
    quality
    D
    maintenance
    A professional chart generation MCP server for Claude Code. Drop a charts-theme.json into any project and Claude can generate beautiful, on-brand charts output as slide-ready PNG and SVG files — fully local, no API keys required.
    -