What can you do with this server?

This server lets you discover, configure, and render word-sized microcharts — suitable for AI-generated content, UIs, and surfaces that can't run React directly. * find_microchart: Describe what your data needs to show in plain language (e.g., "is it trending?", "part to whole") and get a ranked list of matching chart types with reasons why each fits — optionally filtered by data shape. * get_microchart: Look up a specific chart by slug (e.g., "sparkline") to retrieve its import paths, available props, data shape, best-use/avoid guidance, a copy-runnable code example, and a ready-to-use sample object you can pass directly to the render tool. * render_microchart: Render a chart to a self-contained SVG (with embedded styles) and generated accessible alt text — useful for chat replies, emails, or static documents that can't run React. Supports svg and bare output formats.

Which integrations are available for this server?

Provides same chart-finding and rendering capabilities as Vercel AI SDK tools, enabling microcharts within AI-powered applications built on Vercel.

microcharts

by ganapativs

Overview Schema Related Servers Score Discussions

TypeScript

@microcharts/react

Word-sized charts for React — zero runtime dependencies, ~2–7 kB interactive · ~1–4 kB static, accessible by default, and server-component safe.

npm gzip per chart zero dependencies types React 18 · 19 MIT Reviewed with Argos

Docs · Gallery · Quickstart · AI usage · llms.txt

microcharts is 106 tiny, handcrafted chart types built to sit inside an interface: a sentence, a table cell, a KPI card, a tab header, a streamed AI reply. The grammar is small enough for a model to emit correctly mid-sentence, and every chart describes itself in words, so a chart an LLM streams into a chat reply is one a person can read and check.

Status: tested and in production use, but not across every stack and edge yet. If you hit something, open an issue on GitHub.

Why

AI-native. A chart is plain data plus a generated sentence. One grammar across all 106 types — a model that has seen one chart can write them all. → AI usage
Zero dependencies. No chart engine, no D3 — just SVG. React is the only peer. CI-enforced, forever.
Server-component safe. Static charts are hook-free and render to HTML with zero client JavaScript. Interactivity is a separate opt-in /interactive import.
Accessible by default. Every chart is an img with a natural-language summary built from your data; it updates when the numbers do. → Accessibility
Tiny. ~2–7 kB interactive · ~1–4 kB static gzip per chart, budget-gated in CI. Every type has one documented, honest encoding channel and a stated precision.
Motion, opt-in. Interactive charts draw on with animate plus one import "@microcharts/react/motion", and glide continuous marks when data updates. Entrances respect prefers-reduced-motion and never replay over server-rendered HTML. → Motion

Related MCP server: ECharts MCP

Install

npm install @microcharts/react

Import the stylesheet once at the root of your app — it carries every theming token and chart style in a low-specificity cascade layer, so your own styles always win:

// app/layout.tsx
import "@microcharts/react/styles.css";

Your first chart

Every chart renders from data alone. This works in a React Server Component with zero client JavaScript — pure SVG, and its accessible name is generated from the data.

import { Sparkline } from "@microcharts/react/sparkline";

<Sparkline data={[3, 5, 4, 8, 6, 9]} title="Weekly revenue" />;

Each chart imports from its own subpath, so you only ship what you use. Every chart follows the same two-entry pattern: a static default, and an /interactive twin.

Add interactivity

Need hover, keyboard navigation, touch, or live announcements? Import the same chart from /interactive. The rendered output and the accessible name are identical, because the interactive entry composes its static twin. It only adds props; you opt into the client component where it matters.

import { Sparkline } from "@microcharts/react/sparkline/interactive";

<Sparkline data={[3, 5, 4, 8, 6, 9]} title="Weekly revenue" />;

Every interactive chart shares one contract, so you learn it once. Hover or arrow keys make a unit active; a click, tap, Enter, or Space selects it and pins the readout so it survives blur; Escape or a press outside the chart clears; Home/End jump to the ends. Read it back with onActive and onSelect — payload { index, value, label?, formatted? }, where value is the raw number and formatted is the chart's ready-to-display string — and control the pin with selectedIndex / defaultSelectedIndex. Set readout={false} to hide the in-chart value chip and render datum.formatted wherever you like. Single-unit scalar charts (Delta, Progress, StatusDot, Bullet, …) take onSelect alone.

<Sparkline data={[3, 5, 4, 8, 6, 9]} onActive={(d) => setHovered(d?.value ?? null)} onSelect={(d) => pin(d)} />

Annotate with children

Thresholds, markers, and target zones are children — the same grammar on every chart that supports them:

import { Sparkline } from "@microcharts/react/sparkline";
import { Threshold, Marker } from "@microcharts/react/annotations";

<Sparkline data={[120, 180, 240, 210, 260]} title="Latency p95">
  <Threshold y={200} label="SLO" />
  <Marker x={2} celebrate />
</Sparkline>;

Theme it

About two dozen --mc-* CSS custom properties are the runtime contract; presets are token bundles. Set one on a subtree with the provider — presets are visual only and never change what the data means:

import { MicroProvider } from "@microcharts/react";

<MicroProvider theme="editorial">
  <Sparkline data={[3, 5, 4, 8, 6, 9]} />
</MicroProvider>;

Presets: modern (default), editorial, mono, vivid, plus output-context print and eink. Dark mode is hand-tuned, not inverted. For a whole brand theme, defineTheme (from @microcharts/react/theme) derives a matched, color-blind-safe palette and dark twins from one accent:

import { defineTheme } from "@microcharts/react/theme";

const brand = defineTheme({ accent: "#6d28d9" });
<MicroProvider style={brand.style}>…</MicroProvider>;

Retune density with one scalar (--mc-density), give figures their own face (--mc-font-numeric), or recolor a single categorical chart with a colors array. → Theming guide

The catalog

106 stable chart types — 34 core, 26 decision, 23 expressive, 23 frontier — grouped by the question each one answers. data alone always renders something correct, and a prop name means the same thing on every chart (domain, color, title, summary, label, format…), so picking a chart is picking the question you need answered.

Sparklines, bars, deltas, and bullets through bump charts, funnels, honeycombs, calendar strips, and confidence bands — browse them all in the live gallery →

Not shipping, on purpose: pie, needle-gauge/speedometer, battery, waffle, violin. Each fails at micro scale or on the honest-encoding bar, and each has an in-catalog replacement (Bullet for gauges, SegmentedBar for pie, MicroBox for violin). → what to use instead

Made for models

A model writes the chart; a person reads it. The docs site publishes machine surfaces alongside the human ones:

Surface	What it is
`/llms.txt`	Curated map of the catalog and guides
`/llms-full.txt`	The complete generated docs corpus
`/catalog.json`	Every chart's name, import path, props, data shapes

The MCP server

The surfaces above are for reading. @microcharts/mcp lets an assistant call the library directly: a Model Context Protocol server that runs on your machine over stdio, with three tools backed by this library — find the chart type that answers a question, get its exact props and a ready-to-render sample, and render it to a self-contained SVG with the generated alt text attached.

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

Works in Claude Desktop, Claude Code, Cursor, and VS Code; nothing is hosted and no key is involved. The same three capabilities ship as Vercel AI SDK tools on the @microcharts/mcp/ai-sdk subpath. Full reference: microcharts.dev/docs/mcp. Also listed in the Glama MCP registry.

Compatibility

React 18 and 19. ESM-only, per-component subpath exports, types-first export conditions. Static charts render in any RSC or SSR setup with no client runtime.

sideEffects is a two-entry allowlist, never false: styles.css and the opt-in ./motion engine are both imported for their side effects, and false would let a bundler drop them. Every other module is side-effect free and tree-shakes normally, and since charts ship as per-component subpaths, you only pay for the ones you import.

Contributing

pnpm install
pnpm check     # typecheck + lint + format + test + knip
pnpm size      # gzip budgets (needs a build first)
pnpm build

Bug fixes and fixes to existing charts are the most useful thing to send. New props and new chart types are open but held to a high bar — the catalog is already broad at 106 types, so a new one needs a question the others can't answer. Either way, open an issue and wait for a yes before you open a PR. CONTRIBUTING.md has the policy, the CI gates, and what a good bug report contains.

License

MIT © Ganapati V S

Available Tools

3 tools

find_microchartFind a chart by questionA

Rank microcharts chart types against a plain-language question about data ("is it trending?", "error budget", "part to whole"). Returns candidates with the reason each matched. Start here when you know the question, not the chart.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (default 6).
`question`	Yes	What the data needs to show, in plain language.
`dataShape`	No	Optional filter, e.g. "number[]".

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

While no annotations are provided, the description discloses the tool returns 'candidates with the reason each matched', which implies a read-only search. However, it does not explicitly state no side effects, which would be ideal.

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 long, front-loaded with the core action, and contains no extraneous information. Every sentence serves a purpose.

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 three parameters are fully described, an output schema exists (covering return values), and the sibling tool is mentioned, the description provides a complete context for the agent to select and invoke the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, but the description adds value with examples for 'question' (e.g., 'is it trending?') and clarifies 'dataShape' as an optional filter. This goes beyond the schema's basic descriptions.

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 it 'ranks microcharts chart types against a plain-language question', using a specific verb and resource. It distinguishes itself from the sibling 'render_microchart' by referring to 'chart types' rather than rendering.

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

Usage Guidelines5/5

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

The description explicitly says 'Start here when you know the question, not the chart', providing clear when-to-use guidance and implying that 'render_microchart' is the alternative for known charts.

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

get_microchartGet a chart's props + exampleA

Full wiring detail for one chart by slug: import paths, its props plus the shared props, data shape, best/avoid guidance, a copy-runnable example, and sample — the example as JSON props you can pass straight to render_microchart.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Chart slug, e.g. "sparkline".

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`slug`	Yes
`props`	Yes
`sample`	No	Ready-to-render props — pass straight to render_microchart.
`status`	Yes
`bestFor`	Yes
`example`	Yes
`gotchas`	No	Behavior no prop description carries: documented caps, inputs the component derives, how format meets the chart's own sign or unit, and sizing knobs that are not width/height. Read before writing props.
`tagline`	Yes
`avoidFor`	Yes
`encoding`	Yes
`maxWidth`	No	Authored maximum width prop, viewBox units. Past it the geometry stops scaling and the extra box is whitespace — scale with CSS instead. Absent on charts sized by cell, by content, or by CSS.
`dataShape`	Yes
`maxHeight`	No	Authored maximum height prop, viewBox units.
`sharedProps`	Yes
`staticImport`	Yes
`interactiveImport`	No

TDQS

A4.2/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 lists exactly what is returned (import paths, props, data shape, best/avoid guidance, copy-runnable example, and sample), providing good transparency for a read-only retrieval tool. It does not mention side effects or errors, but for a get tool this is adequate.

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

Conciseness4/5

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

The description is a single comprehensive sentence that front-loads the key action and enumerates contents efficiently. It is slightly run-on but not overly verbose, and every part adds value.

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?

With only one parameter and an output schema present, the description thoroughly covers what the tool provides and even connects to render_microchart via the sample field. There are no significant gaps for this simple tool.

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 coverage is 100% with 'slug' described as 'Chart slug, e.g. "sparkline"'. The description only restates 'by slug' without adding extra parameter semantics, so it does not improve upon the schema. Baseline 3 is appropriate.

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 states a specific action: 'Full wiring detail for one chart by slug' and enumerates the exact contents (import paths, props, data shape, guidance, example). It distinguishes from siblings by mentioning the sample can be passed to render_microchart, and the title clarifies it's about props and example.

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?

Clear context: use this tool to get comprehensive details for a known chart slug, and the 'sample' output can be fed to render_microchart. It does not explicitly exclude when to use find_microchart, but the sibling names imply differentiation, so there is clear context without explicit exclusions.

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

render_microchartRender a chart to SVGA

Render a chart to a finished, self-contained SVG (styles embedded) plus its generated alt text — for surfaces that can't run React. Pass the series as data; put other props (value, target, curve, color, width) in props. Each chart takes its own data shape — get_microchart returns a valid sample to adapt.

ParametersJSON Schema

Name	Required	Description
`data`	No	Primary series (array), or a keyed object for charts that take one; omit for scalar charts.
`type`	Yes	Chart slug, e.g. "sparkline".
`props`	No	Other props (value, target, color, …).
`format`	No	`svg` (default) or `bare`.

Output Schema

ParametersJSON Schema

Name	Required	Description
`svg`	Yes
`width`	Yes
`height`	Yes
`library`	Yes
`summary`	Yes	The chart's generated accessible name — its alt text.
`mimeType`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that the output is a self-contained SVG with styles embedded and includes alt text. No mention of authorization or rate limits, but since it's a non-destructive rendering operation, the transparency is adequate.

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?

Two sentences: first states purpose, second gives input guidance. No unnecessary words. Highly concise and well-structured.

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 4 parameters, 100% schema coverage, and presence of output schema, the description provides sufficient context: input structure, use case, and reference to sibling tool for data shapes. Complete for a rendering tool.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds value by explaining that 'data' holds the series, 'props' holds other configuration like value, target, etc., going beyond schema definitions.

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 it renders a chart to a self-contained SVG plus alt text for environments that can't run React, and distinguishes from sibling get_microchart which returns a sample.

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

Usage Guidelines5/5

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

Explicitly says when to use ('for surfaces that can't run React'), how to structure input ('Pass the series as data; put other props...'), and advises consulting get_microchart for valid data shapes.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: find_microchart for chart selection, get_microchart for details, render_microchart for output. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_microchart pattern (find_, get_, render_) using snake_case, making it predictable and easy to understand.

Tool Count4/5

Three tools is minimal but well-scoped for the domain of microchart usage. While more tools could exist, the current set covers the essential workflow without being overly sparse.

Completeness4/5

The toolset covers discovery, reference, and rendering—key stages of using microcharts. Missing tools like listing all chart types or custom chart creation, but the core functionality is complete.

Maintenance

ActivityActive

ResponsivenessSlow

Resources

Need Help?

Related Servers

Related MCP Connectors

Charts by Szum A
io.szum
Create, inspect, manage, and render charts and data visualizations as SVG/PNG or interactive embeds.
Data Visualization Image & Video Processing
132
ChartPane
io.github.ahmadsl
Renders interactive Chart.js charts and dashboards inline in AI conversations.
Developer Tools Data Platforms
21
mcp
com.slickfast
Render 47 chart types and tiled dashboards as PNG/SVG. Deterministic, no headless browser.
Data Visualization Image & Video Processing
1
Prism — Crossdeck
com.cross-deck
Ask your app anything — revenue, errors, read-cost, growth — and get rendered charts back.
Monitoring Observability Data Visualization
2

Related MCP Servers

MCP Server Chartofficial
Data Platforms Image & Video Processing Virtualization
antvis
A
license
B
quality
B
maintenance
mcp-server-chart
Updated 9 days ago (2026-08-27 01:50 UTC)
61
26
2,845
4,345
TypeScript
MIT
ECharts MCP
apache
A
license
Not graded
quality
C
maintenance
An MCP (Model Context Protocol) server that enables LLMs to generate ECharts visualizations by accepting chart type, data and parameters and returning cloud image URLs of the generated charts.
Updated 23 days ago (2026-08-12 20:00 UTC)
19
81
Apache 2.0
Vega-Lite MCP Server
Documentation Access Developer Tools Data Platforms
inteligencianegociosmmx
A
license
A
quality
D
maintenance
Provides AI assistants with access to Vega-Lite documentation, visualization examples, and specification validation tools. Enables searching docs, retrieving examples by category, validating JSON specs, and accessing schema information for creating data visualizations.
Updated a year ago (2025-10-09 02:32 UTC)
4
1
MIT
mcp-dashboards
Data Platforms Data Visualization Finance
KyuRish
A
license
A
quality
B
maintenance
Renders 45+ interactive chart types, dashboards, and KPI widgets directly inside AI conversations. Supports drill-down, live API polling, 20 themes, and one-click export to PNG, PowerPoint, and A4 documents.
Updated 13 days ago (2026-08-23 08:25 UTC)
40
250
44
Functional Source , Version 1.1, MIT Future

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ganapativs/microcharts'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@microcharts/react

Why

Install

Your first chart

Add interactivity

Annotate with children

Theme it

The catalog

Made for models

The MCP server

Compatibility

Contributing

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

MCP Server Chartofficial

ECharts MCP

Vega-Lite MCP Server

mcp-dashboards

Latest Blog Posts

MCP directory API