Skip to main content
Glama
palewire

datawrapper-mcp

by palewire
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Export Chart Png

export_chart_png
Read-onlyIdempotent

Exports a Datawrapper chart as a PNG image for inline display or download, with optional zoom for higher resolution. Use only when the user explicitly requests the chart image.

Instructions

⚠️ DATAWRAPPER MCP TOOL ⚠️ This is part of the Datawrapper MCP server integration.

Export a Datawrapper chart as PNG and display it inline. The chart must be created first using create_chart. Supports high-resolution output via the zoom parameter. IMPORTANT: Only use this tool when the user explicitly requests to see the chart image or export it as PNG. Do not automatically export charts after creation unless specifically asked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
zoomNoScale multiplier for resolution, e.g., 2 = 2x resolution
plainNoIf true, exports only the visualization without header/footer
widthNoWidth of the image in pixels (optional)
heightNoHeight of the image in pixels (optional)
timeoutNoSeconds to wait for the export before giving up (optional). Defaults to 30s. Large or complex charts (e.g. high zoom values) may need a longer timeout to finish rendering server-side.
chart_idYesID of the chart to export
transparentNoIf true, exports with transparent background
access_tokenNoOptional Datawrapper API token. When provided, uses the caller's account. When omitted, falls back to the server's DATAWRAPPER_ACCESS_TOKEN env var.
border_colorNoColor of the border, e.g., '#FFFFFF' (optional)
border_widthNoMargin around visualization in pixels

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.0
    • addedInput schema / properties / timeout
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Seconds to wait for the export before giving up (optional).\n     Defaults to 30s. Large or complex charts (e.g. high zoom values)\n     may need a longer timeout to finish rendering server-side."
+}
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the ordering dependency on create_chart, the inline rendering side effect, and the caution against unsolicited exports. It does not discuss the server-side rendering wait or failure modes, which the schema covers for timeout only.

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

Conciseness3/5

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

The core content is short and the operational warning is well placed, but the leading '⚠️ DATAWRAPPER MCP TOOL ⚠️' banner and horizontal rule occupy the front-loaded position without conveying any actionable information. Those two lines are decoration that a selector cannot use.

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?

For a single-required-parameter export tool with no output schema, the description covers the prerequisite, the inline return behavior, the explicit-use trigger, and defers all field detail to a fully documented schema. Nothing needed to invoke it correctly is missing.

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%, with all ten parameters (zoom, plain, width, height, timeout, access_token, border_*, transparent) individually documented, so the schema does the heavy lifting. The description only echoes the zoom parameter's high-resolution role and adds no syntax, format, or interaction detail beyond it.

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 sentence 'Export a Datawrapper chart as PNG and display it inline' gives a specific verb (export), resource (chart), and output format (PNG), which clearly separates it from mutating siblings like create_chart or delete_chart. It does not explicitly contrast itself with the read sibling get_chart, so it stops short of full sibling differentiation.

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?

It states a hard prerequisite ('The chart must be created first using create_chart') and an explicit when-not rule ('Only use this tool when the user explicitly requests... Do not automatically export charts after creation unless specifically asked'). Both the triggering condition and the exclusion are spelled out, leaving nothing to inference.

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

Deploy Server

Other Tools