How do I use image-charts-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@image-charts-mcp create a bar chart showing quarterly revenue by region" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

image-charts-mcp

Official

by image-charts

Overview Schema Related Servers Score Discussions

TypeScript

Remote

image-charts-mcp

A Model Context Protocol server that turns an agent's chart request into a permanent, hosted Image-Charts image URL.

The URL renders server-side and embeds anywhere an image does — Markdown, HTML <img>, email, Slack, PDF, no-code and low-code tools — with no chart library and no runtime on the client. The agent gets back a string; the picture appears wherever that string is dropped.

Why a URL

Most chart tooling hands an agent raw bytes or an ephemeral in-memory preview that lives and dies inside the session. A hosted URL is different:

Persistent — the same link keeps rendering long after the conversation ends.
Portable — paste it into an email, a Notion page, a Slack message, a PDF, a Jira ticket. It just shows up.
Zero-runtime — the receiving surface needs nothing but the ability to display an image. No JavaScript, no build step, no dependency.
Deterministic — the chart is fully described by the URL, so it is cacheable and reproducible.

Related MCP server: Datawrapper MCP

Install

No install step — run it straight from npm:

npx -y image-charts-mcp

Client configuration

Add the server to your MCP client (Claude Desktop, Claude Code, Cursor, or any MCP-capable host):

{
  "mcpServers": {
    "image-charts": {
      "command": "npx",
      "args": ["-y", "image-charts-mcp"],
      "env": {
        "IMAGE_CHARTS_SECRET": "",
        "IMAGE_CHARTS_HOST": ""
      }
    }
  }
}

Both env vars are optional:

Variable	Purpose
`IMAGE_CHARTS_SECRET`	Image-Charts Enterprise HMAC signing key. When set together with an account id (`icac`), every URL is signed. Never logged.
`IMAGE_CHARTS_HOST`	Image-Charts Dedicated Cloud host (e.g. `charts.acme.com`). URLs point at this host and are never signed.

Leave them empty for the free, watermarked tier.

Transports

stdio (default) — what MCP clients use.
StreamableHTTP (stateless) — npx -y image-charts-mcp --transport http --port 3000, served at http://127.0.0.1:3000/mcp.

Tools

`create_chart` — describe a chart, get a URL

High-level, Image-Charts-native description. You pick a semantic type and supply data; the server maps it to the correct Image-Charts parameters.

type is one of: bar, bar_grouped, bar_stacked, bar_horizontal, line, area, pie, doughnut, radar, scatter, qr, graph, gauge.

Common fields: title, series ({ name?, data: number[] }, or { name?, points: {x,y}[] } for scatter), labels, colors (hex without #), legend (true / "top" / "bottom" / "left" / "right"), size ({ width, height }), plus qr / graph / gauge option objects, icac, and format (url / png / both).

Bar chart

{
  "type": "bar",
  "title": "Quarterly revenue",
  "series": [
    { "name": "EU", "data": [120, 90, 140] },
    { "name": "US", "data": [80, 130, 100] }
  ],
  "labels": ["Q1", "Q2", "Q3"],
  "colors": ["4285F4", "DB4437"],
  "legend": "bottom"
}

Pie chart

{
  "type": "pie",
  "title": "Traffic sources",
  "series": [{ "data": [40, 35, 25] }],
  "labels": ["Search", "Direct", "Social"],
  "colors": ["4285F4", "0F9D58", "F4B400"]
}

→ https://image-charts.com/chart?cht=p&chd=a:40,35,25&chs=500x400&chl=Search|Direct|Social&chco=4285F4,0F9D58,F4B400&chtt=Traffic+sources

QR code

{
  "type": "qr",
  "qr": { "data": "https://www.image-charts.com", "errorCorrection": "M", "margin": 4 },
  "size": { "width": 300, "height": 300 }
}

→ https://image-charts.com/chart?cht=qr&chl=https://www.image-charts.com&choe=UTF-8&chld=M|4&chs=300x300

URLs above are shown decoded for readability; the tool returns them percent-encoded.

`image_charts_url` — raw parameter passthrough

The escape hatch. Pass raw Image-Charts parameters (cht, chd, chs, chco, chxt, chxl, chm, chbh, …) and get the hosted URL, signed automatically when applicable. Use it for anything create_chart does not cover.

{ "cht": "lc", "chd": "a:10,40,25,60", "chs": "600x300", "chco": "4285F4", "chm": "B,4285F433,0,0,0" }

`list_chart_types` — discovery

Returns every semantic type, the Image-Charts cht it maps to, a description, the inputs it reads, and the concepts Image-Charts cannot render (funnel, treemap, sankey, heatmap, and so on). Call it first if you are unsure which type to use.

Enterprise signing

Image-Charts Enterprise requires each URL to carry an HMAC-SHA256 signature. This server handles it for you:

Set IMAGE_CHARTS_SECRET in the server's environment (it stays server-side and is never logged).
Pass your account id as icac on create_chart or image_charts_url.

When both are present the returned URL includes &ichm=…:

https://image-charts.com/chart?icac=ic_demo_account&cht=bvg&chd=a:1,2,3&chs=700x400&…&ichm=26d6d5b3…

If the secret is not configured, a bare icac cannot be signed, so it is dropped and you get a valid free-tier URL instead of a broken one. On Dedicated Cloud (IMAGE_CHARTS_HOST) signing is not used at all — the dedicated host handles authorization at the edge.

Development

npm install
npm run build       # tsup → dist/cli.js
npm run typecheck   # tsc --noEmit
npm test            # vitest (black-box, real Image-Charts URL builder, no mocks)

License

MIT

Available Tools

3 tools

create_chartCreate a hosted chartA

Describe a chart semantically (bar, line, area, pie, doughnut, radar, scatter, qr, graph, gauge, …) and get back a permanent, hosted Image-Charts image URL that renders server-side and embeds anywhere. No client-side chart library required.

ParametersJSON Schema

Name	Required	Description
`qr`	No	QR-code options (type = qr).
`icac`	No	Image-Charts Enterprise account id. When the IMAGE_CHARTS_SECRET env var is also set, the URL is HMAC-SHA256 signed (&ichm=…). Ignored on Dedicated Cloud (IMAGE_CHARTS_HOST).
`size`	No	Pixel size. Each side <= 999 and width*height <= 998001. Sensible per-type defaults are used when omitted (e.g. 700x400 for bar/line, 300x300 for qr).
`type`	Yes	Semantic chart type. Call list_chart_types for the full catalog and the Image-Charts `cht` each maps to.
`gauge`	No	Gauge options (type = gauge).
`graph`	No	GraphViz options (type = graph).
`title`	No	Title drawn above the chart.
`colors`	No	Hex colors WITHOUT a leading #, one per series (or per slice for pie/doughnut).
`format`	No	url (default) returns only the hosted URL; png also fetches the rendered PNG; both returns the URL and the image.
`labels`	No	Category / slice labels: x-axis ticks for bar & line, slice labels for pie & doughnut, axis labels for radar. An empty string skips one label.
`legend`	No	Show a legend built from series names. true = right side; or pick a side explicitly.
`series`	No	One or more data series. Required for every type except qr and graph. Use `data` for numeric series, `points` for scatter.

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the transparency burden. It discloses key behavior: returns a permanent, hosted URL that renders server-side and works without a client-side library. However, it omits operational details like authentication (icac), network effects, rate limits, or the fact that format=png fetches the image, which are important for a creation tool.

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 concise sentences that front-load the action and result. It includes valuable context (permanent URL, server-side rendering, no client-side library) without waste. Every word adds meaning.

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

Completeness3/5

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

Given the tool's complexity (12 parameters, nested objects, no output schema, no annotations), the description gives a high-level purpose but does not mention the required 'type' parameter, the optional output format (url/png/both), or how to handle authentication. The rich schema compensates, but the description alone is not fully complete for correct invocation.

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 itself adds no parameter-level meaning, but the schema fully documents each parameter, including nested objects and constraints, so the agent can rely on the schema.

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

Purpose4/5

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

The description clearly states the tool creates a hosted chart URL from a semantic chart description, listing supported chart types. It names the specific resource and outcome (Image-Charts URL), but does not explicitly differentiate itself from siblings like image_charts_url.

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

Usage Guidelines3/5

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

The description implies use for server-side rendering and embedding without a client-side library, providing some context. However, it does not explicitly state when to use this tool over alternatives like image_charts_url or list_chart_types, nor does it mention exclusions.

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

image_charts_urlBuild a raw Image-Charts URLA

Escape hatch for full control: pass raw Image-Charts parameters (cht, chd, chs, chco, chxt, chxl, chm, …) and get the hosted image URL. Signs the URL automatically when icac is provided and IMAGE_CHARTS_SECRET is set.

ParametersJSON Schema

Name	Required	Description
`chd`	No	Chart data, e.g. "a:1,2,3\|4,5,6".
`chf`	No	Background / gradient fill.
`chg`	No	Grid lines.
`chl`	No	Labels (bar/pie/slice) or QR/GraphViz payload.
`chm`	No	Compound markers, line fills, value labels.
`chs`	No	Size <width>x<height>.
`cht`	No	Chart type, e.g. bvg, bvs, lc, p, pd, r, lxy, qr, gv.
`chan`	No	Animation (renders a GIF).
`chbh`	No	Bar width/spacing (not in the SDK typings; forwarded verbatim).
`chbr`	No	Bar corner radius.
`chco`	No	Series/element colors (hex, comma & pipe separated).
`chdl`	No	Legend labels, e.g. "A\|B\|C".
`chds`	No	Custom data scaling.
`chld`	No	QR error-correction\|margin, e.g. "L\|4".
`chli`	No	Doughnut inside label.
`chls`	No	Line thickness/dash style.
`chma`	No	Chart margins.
`choe`	No	QR data encoding (UTF-8).
`chof`	No	Output extension hint.
`chts`	No	Title color,size[,align,family,style].
`chtt`	No	Chart title.
`chxl`	No	Custom axis labels, e.g. "0:\|A\|B\|C".
`chxr`	No	Axis ranges, e.g. "0,0,100".
`chxs`	No	Axis label styles.
`chxt`	No	Visible axes, e.g. "x,y".
`icac`	No	Enterprise account id; signs the URL when IMAGE_CHARTS_SECRET is set.
`icff`	No	Google Font family (Enterprise).
`icfs`	No	Default font style.
`chdlp`	No	Legend position (r/l/t/b).
`chdls`	No	Legend color,size.
`icqrb`	No	QR background color.
`icqrf`	No	QR foreground color.
`format`	No	url (default), png (also fetch image), or both.
`iclocale`	No	Locale (ISO 639-1).
`icretina`	No	Retina mode (Enterprise).

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds meaningful context by stating that the URL is signed automatically when icac is provided and IMAGE_CHARTS_SECRET is set. It also implies a pass-through behavior ('raw parameters') without validation, which is useful. However, it does not disclose return format variations (e.g., what happens when format='png') or any error behavior, leaving some gaps.

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 with no wasted words. It front-loads the key concept ('Escape hatch for full control'), then provides the mechanism and an important behavioral note. Every sentence earns its place.

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

Completeness3/5

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

The tool has 35 parameters, no output schema, and no annotations, so the description needs to cover more ground. It clearly explains the core behavior and signing, but it does not clarify how the 'format' parameter affects the output (url vs png vs both). This is a notable omission given that the schema includes a format param with enum values, and without an output schema the agent cannot infer the return structure. Thus, the description is adequate but not complete.

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?

The schema description coverage is 100%, so the baseline is 3. The description lists several example parameters (cht, chd, chs, chco, chxt, chxl, chm) but does not add new semantics beyond what the schema already provides. The mention of signing with icac is also present in the schema's parameter description, so the description adds no extra value for parameter understanding.

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 purpose with a specific verb and resource: 'pass raw Image-Charts parameters ... and get the hosted image URL.' It also distinguishes itself from siblings by calling it an 'escape hatch for full control' and mentioning the signing behavior, which differentiates it from a high-level chart creation tool like create_chart.

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 phrase 'escape hatch for full control' implies this tool is for users who need to bypass higher-level abstractions and specify raw parameters directly. This provides clear context, but it does not explicitly mention when to prefer this over create_chart or list_chart_types, nor does it state when not to use it. The guidance is implied rather than explicit.

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

list_chart_typesList supported chart typesA

Discovery: returns every semantic type accepted by create_chart, the Image-Charts cht it maps to, a description, and which inputs it reads — plus the concepts Image-Charts cannot render.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/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 what the tool returns (semantic types, mappings, descriptions, inputs, limitations) and implies a safe read-only operation. Missing details like response format or pagination prevent a higher score.

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?

A single, information-dense sentence front-loaded with 'Discovery:' covers purpose, content, and limitations efficiently. Every clause adds value without redundancy.

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?

The tool has no parameters and no output schema, but the description thoroughly explains what it returns and its scope relative to siblings. It fully covers the discovery use case, including what Image-Charts cannot render.

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?

With zero parameters and 100% schema description coverage, the baseline is 4. The description's mention of returned content (mappings, inputs) provides context beyond the empty schema, though no parameter-level detail is needed.

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 returns every semantic type accepted by create_chart, including mappings, descriptions, inputs, and unrenderable concepts. This specific verb+resource combination distinguishes it from sibling tools like create_chart and image_charts_url.

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 prefix 'Discovery:' signals the intended use case as a discovery/list tool, contrasting with the action-oriented siblings. However, it does not explicitly state when not to use it or name alternatives, so it falls short of full explicit guidance.

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/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: high-level semantic chart creation, low-level raw parameter control, and type discovery. No overlap or ambiguity between them.

Naming Consistency3/5

Two tools use verb_noun naming (create_chart, list_chart_types), but image_charts_url is a noun phrase without a verb, breaking the pattern. Readable but inconsistent.

Tool Count5/5

Three tools is appropriately scoped for a chart-generation server, covering creation, raw access, and discovery without unnecessary bloat.

Completeness5/5

The surface covers the full chart workflow: semantic creation, raw parameter pass-through, and type discovery. No obvious gaps for the server's stated purpose.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Living Memory
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
32
agentverse
io.github.doc2mcp
MCP server for agentverse documentation, generated by doc2mcp.
Agent Orchestration Documentation Access
24
ClawLink
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

mcp-plots
Open Data
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.
Updated 9 months ago (2025-12-02 02:59 UTC)
2
4
MIT
Datawrapper MCP
hqu
A
license
A
quality
D
maintenance
An MCP server that enables AI assistants to create, update, and publish Datawrapper charts through natural language. It provides tools for data synchronization, visual configuration, and retrieving chart images or editor links.
Updated 6 months ago (2026-03-02 02:56 UTC)
8
MIT
Table Charts
Data Visualization Developer Tools
Browncabinet
A
license
A
quality
A
maintenance
TableCharts MCP Server gives any LLM assistant the ability to instantly convert tabular data into beautiful, hosted, interactive dashboards. Simply provide JSON rows, raw CSV text, or a public URL (Notion page, Google Sheet, or Salesforce report), and get back a shareable dashboard URL plus an embeddable iframe code — all in one tool call. Supports 6 chart types: bar, line, area, pie, scatter, a
Updated 2 months ago (2026-07-04 00:17 UTC)
2
17
MIT
chartpane
Data Visualization Developer Tools
ahmadsl
A
license
Not graded
quality
D
maintenance
MCP server that renders interactive Chart.js charts (bar, line, pie, doughnut, etc.) inline in Claude's UI.
Updated 6 months ago (2026-03-04 09:53 UTC)
1
MIT

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/image-charts/image-charts-mcp'

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

image-charts-mcp

Why a URL

Install

Client configuration

Transports

Tools

create_chart — describe a chart, get a URL

image_charts_url — raw parameter passthrough

list_chart_types — discovery

Enterprise signing

Development

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`create_chart` — describe a chart, get a URL

`image_charts_url` — raw parameter passthrough

`list_chart_types` — discovery