Use this MCP server to create, style, publish, inspect, update, delete, and export Datawrapper charts through an AI assistant.
Discover available Datawrapper chart types and fetch detailed configuration schemas for each.
Create charts from inline list, dict, JSON, or CSV/JSON file data with customizable titles, colors, axes, labels, annotations, tooltips, and other styling.
Update existing chart data or high-level configuration, but not the chart type, which is immutable.
Publish charts to make them publicly accessible and retrieve public/edit URLs.
Retrieve an existing chart's configuration, metadata, and URLs for inspection or cloning.
Delete charts permanently.
Export charts as PNG with options for zoom, width, height, plain mode, transparency, and borders.
Authenticate using the DATAWRAPPER_ACCESS_TOKEN environment variable, an Authorization Bearer header for hosted deployments, or a per-tool access_token argument.
Pass custom free-text guidance to MCP clients via DATAWRAPPER_MCP_INSTRUCTIONS.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@datawrapper-mcp Create a line chart from this data: 2020 15, 2021 20, 2022 25"
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.
A Model Context Protocol (MCP) server and app for creating Datawrapper charts using AI assistants. Built on the datawrapper Python library.
Status: early and experimental. This project — including its Claude Code/Desktop plugin and marketplace listing — is under active development, and behavior can change between releases. In particular, the plugin/marketplace install path has known gaps (see issue #78) — don't treat it yet as a finished, zero-maintenance install path for a wider rollout.
You can provide a data file and simply ask for the chart you want. The draft will soon appear in the panel.
Here's a more complete example showing how to create, publish, update, and display a chart by chatting with the assistant:
"Create a datawrapper line chart showing temperature trends with this data:
2020, 15.5
2021, 16.0
2022, 16.5
2023, 17.0"
# The assistant creates the chart and returns the chart ID, e.g., "abc123"
"Publish it."
# The assistant publishes it and returns the public URL
"Update chart with new data for 2024: 17.2°C"
# The assistant updates the chart with the new data point
"Make the line color dodger blue."
# The assistant updates the chart configuration to set the line color
"Show me the editor URL."
# The assistant returns the Datawrapper editor URL where you can view/edit the chart
"Show me the PNG."
# The assistant embeds the PNG image of the chart in its contained response.
"Suggest five ways to improve the chart."
# See what happens!Related MCP server: Draw.io MCP Server
Tool | Description |
| List available chart types with descriptions |
| Get the full configuration schema for a chart type |
| Create a new chart with data and configuration |
| Update an existing chart's data or styling |
| Publish a chart to make it publicly accessible |
| Retrieve a chart's configuration and metadata |
| Permanently delete a chart |
| Export a chart as a PNG image |
bar, line, area, arrow, column, multiple column, scatter, stacked bar
Use list_chart_types to see descriptions, then get_chart_schema to explore configuration options for any type.
A Datawrapper account (sign up at https://datawrapper.de/signup/)
An MCP client such as Claude or OpenAI Codex
Python 3.10 or higher
Create a new API token
Add it to your MCP configuration as shown in the installation guide
{
"mcpServers": {
"datawrapper": {
"command": "uvx",
"args": ["datawrapper-mcp"],
"env": {
"DATAWRAPPER_ACCESS_TOKEN": "your-token-here"
}
}
}
}For other clients (Claude Desktop, Claude.ai, Cursor, VS Code Copilot, ChatGPT, OpenAI Codex, OpenClaw) and Kubernetes deployment, see the installation guide.
Installing via a plugin marketplace/directory (Claude Desktop's plugin browser, ClawHub, etc.) is still experimental. These interactive install flows currently have no working way to collect required environment variables like
DATAWRAPPER_ACCESS_TOKEN— see issue #78 for details. The manually-edited config shown above (and throughout the installation guide) is the reliable path today.
When connecting to a hosted instance of the server over HTTP, you can authenticate
with your own Datawrapper API token by sending it in the Authorization header:
Authorization: Bearer <your-datawrapper-api-token>This ensures charts are created under your account instead of the server operator's. The token is read from the header automatically — no need to include it in every tool call.
You can also pass access_token directly as a tool argument, which takes precedence
over the header. When neither is provided, the server falls back to its
DATAWRAPPER_ACCESS_TOKEN environment variable.
Set DATAWRAPPER_MCP_INSTRUCTIONS to have the server hand your own free-text
guidance to connecting MCP clients (many, including Claude, fold this into
the model's context). Use it for house style rules — required fields, naming
conventions, and the like — without forking the server:
"env": {
"DATAWRAPPER_ACCESS_TOKEN": "your-token-here",
"DATAWRAPPER_MCP_INSTRUCTIONS": "Every chart needs alt text and a CMS slug in its notes field."
}Client | Config file | Transport |
Claude Desktop |
| stdio or streamable-http |
Claude.ai | Personal or org connector | streamable-http |
Claude Code | Plugin marketplace or | stdio |
VS Code Copilot |
| stdio |
Cursor |
| stdio or streamable-http |
ChatGPT | Dev Mode settings | streamable-http only |
OpenAI Codex |
| stdio |
OpenClaw | ClawHub plugin or | stdio |
⚠️ DATAWRAPPER MCP TOOL ⚠️ This is part of the Datawrapper MCP server integration.
Check which Datawrapper account is currently authenticated, without creating, modifying, or deleting anything. Use this to troubleshoot access issues - especially when connected through a personal Claude connector using a per-user Authorization header, where a misconfigured header silently falls back to a different account instead of raising an error. If the reported email isn't the one you expected, the header isn't reaching the server correctly.
| Name | Required | Description | Default |
|---|---|---|---|
| access_token | No | Optional Datawrapper API token. When provided, checks that token specifically. When omitted, checks whichever credential this call would otherwise use (the BYOK header, or the server's DATAWRAPPER_ACCESS_TOKEN env var). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: a misconfigured Authorization header fails silently to a different account rather than erroring, which is exactly the diagnostic nuance an agent needs. It does not say what happens when the token itself is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The '⚠️ DATAWRAPPER MCP TOOL ⚠️ / This is part of the Datawrapper MCP server integration. / ---' block is pure boilerplate that pushes the actual purpose statement down. The remaining sentences are tight and well-structured, but roughly a third of the text is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile and an output schema covering the return value (the reported account email), the description supplies the operational context an agent needs. Minor gap: it does not describe behavior on an invalid or expired token.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the access_token description already explains the provided-vs-omitted behavior, including the BYOK header and DATAWRAPPER_ACCESS_TOKEN env var fallback. The prose description adds no parameter meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Check which Datawrapper account is currently authenticated.' That is immediately distinguishable from every sibling, all of which perform chart CRUD or export operations. An agent can select this tool without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use guidance: 'Use this to troubleshoot access issues,' with a concrete failure scenario (per-user Authorization header silently falling back to another account). It does not name a when-not case or an alternative tool, but no sibling competes for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ THIS IS THE DATAWRAPPER INTEGRATION ⚠️ Use this MCP tool for ALL Datawrapper chart creation.
DO NOT: ❌ Install the 'datawrapper' Python package ❌ Use the Datawrapper API directly ❌ Import 'from datawrapper import ...' ❌ Run pip install datawrapper
This MCP server IS the complete Datawrapper integration. All Datawrapper operations should use the MCP tools provided by this server.
Create a Datawrapper chart with full control using Pydantic models. This allows you to specify all chart properties including title, description, visualization settings, axes, colors, and more. The chart_config should be a complete Pydantic model dict matching the schema for the chosen chart type.
BEST PRACTICES:
Start simple, then add customization based on user feedback
Only apply styling when requested or when it significantly improves readability
Let Datawrapper handle axis scaling automatically unless there's a specific reason to override
QUICK EXAMPLES:
Basic chart with title: chart_config = { "title": "Monthly Sales", "intro": "Sales data for Q1 2024" }
Chart with custom colors: chart_config = { "title": "Product Comparison", "color_category": { "Product A": "#1f77b4", "Product B": "#ff7f0e" } }
Styled line chart: chart_config = { "title": "Sales Trends", "lines": [ {"column": "sales", "width": "style2", "interpolation": "curved"} ], "custom_range_y": [0, 1000] }
STYLING WORKFLOW:
Use list_chart_types to see available chart types
Use get_chart_schema to explore all options for your chosen type
Refer to https://datawrapper.readthedocs.io/en/latest/ for detailed examples
Build your chart_config with the desired styling properties
Common styling patterns:
Colors: {"color_category": {"sales": "#1d81a2", "profit": "#15607a"}}
Line styling: {"lines": [{"column": "sales", "width": "style1", "interpolation": "curved"}]}
Axis ranges: {"custom_range_y": [0, 100], "custom_range_x": [2020, 2024]} NOTE: Datawrapper's automatic axis scaling is excellent. Only set custom ranges when you need specific customization (e.g., comparing multiple charts, forcing zero baseline for specific analytical reasons, or matching a house style guide).
Grid formatting: {"y_grid_format": "0", "x_grid": "on", "y_grid": "on"}
Tooltips: {"tooltip_number_format": "00.00", "tooltip_x_format": "YYYY"}
Annotations: {"text_annotations": [{"x": "2023", "y": 50, "text": "Peak"}]}
See the documentation for chart-type specific examples and advanced patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Chart data. RECOMMENDED: Pass data inline as a list or dict. PREFERRED FORMATS (use these first): 1. List of records (RECOMMENDED): [{"year": 2020, "sales": 100}, {"year": 2021, "sales": 150}] 2. Dict of arrays: {"year": [2020, 2021], "sales": [100, 150]} 3. JSON string of format 1 or 2: '[{"year": 2020, "sales": 100}]' ALTERNATIVE (only for extremely large datasets where inline data is impractical): 4. File path to CSV or JSON: "/path/to/data.csv" or "/path/to/data.json" | |
| chart_type | Yes | Type of chart to create. Use list_chart_types to see all available types. Common types: bar, line, area, arrow, column, multiple_column, scatter, stacked_bar | |
| access_token | No | Optional Datawrapper API token. When provided, charts are created in the caller's account (recommended). When omitted, falls back to the server's DATAWRAPPER_ACCESS_TOKEN env var. | |
| chart_config | Yes | Complete chart configuration as a Pydantic model dict |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds crucial context: this creates a chart in the caller's account or falls back to a server token, and charts are created but not necessarily published. However, it doesn't mention rate limits, what happens on duplicate titles, or whether a token must be configured before use. The 'NOT to use pip' barrier is behavioral context but not about the tool's own traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated. It opens with a large warning block (6 lines) about not using the Python package, which is important but far too verbose for the front of the description. The actual tool purpose is buried after the warning. Then it includes extensive best practices, examples, and a styling workflow that could be condensed. The front-loading is poor; the most critical information (what the tool does) appears after a wall of negative guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is long and contains many details, but it's missing key behavioral context for a mutation tool: whether the chart is immediately live, whether it can be updated with update_chart, and what permissions or setup are required. The extensive examples and best practices are helpful but don't compensate for the lack of workflow context (create -> update -> publish) with siblings. For a tool with 3 required params, no output schema, and openWorldHint=true, it should clarify these points.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters (data, chart_type, access_token, chart_config) are well-documented in the schema itself. The description adds some value by explaining that chart_config is a complete Pydantic model dict and giving styling examples, but the schema already defines the parameter. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (create a Datawrapper chart) and clarifies it offers full control via Pydantic models. However, it doesn't concisely distinguish itself from update_chart or publish_chart - the sibling differentiation is implicit at best. A clear purpose but the critical sibling relationship (create now, publish later) isn't addressed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent NOT to use the Datawrapper Python package or raw API, which is valuable negative guidance against a common hallucination. But it doesn't say when to use create_chart vs update_chart or get_chart. The 'when-not' for external integrations is present, but the 'when-not' for sibling tools is missing. Implied usage rather than explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ DATAWRAPPER MCP TOOL ⚠️ This is part of the Datawrapper MCP server integration.
Delete a Datawrapper chart permanently.
| Name | Required | Description | Default |
|---|---|---|---|
| chart_id | Yes | ID of the chart to delete | |
| access_token | No | Optional Datawrapper API token. When provided, uses the caller's account. When omitted, falls back to the server's DATAWRAPPER_ACCESS_TOKEN env var. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is largely covered by structured data. The description's 'permanently' usefully confirms irreversibility, but it says nothing about the effect on published charts, permission/ownership requirements, or failure behavior when the chart does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two lines of branded boilerplate ('⚠️ DATAWRAPPER MCP TOOL ⚠️' and the server-integration sentence) and a horizontal rule consume space without informing invocation, while the substantive content is a single short sentence. The useful content is present but is padded by non-earning decoration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and annotations cover the destructive/idempotent profile. What remains missing is impact context (e.g., whether deletion affects published charts or is recoverable, and error conditions), which matters for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (chart_id, access_token) are documented in the schema, so the description is not required to compensate. It adds no extra meaning about chart_id format or token fallback behavior beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Delete a Datawrapper chart') and adds an important scope qualifier ('permanently'). It is clear what the tool does, but it does not distinguish itself from siblings like update_chart or publish_chart, which an agent must infer from names alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no statement of prerequisites or alternatives (e.g., 'to modify instead of remove a chart, use update_chart'), and no exclusions. The agent is left to infer that this is the only deletion path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ 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.
| Name | Required | Description | Default |
|---|---|---|---|
| zoom | No | Scale multiplier for resolution, e.g., 2 = 2x resolution | |
| plain | No | If true, exports only the visualization without header/footer | |
| width | No | Width of the image in pixels (optional) | |
| height | No | Height of the image in pixels (optional) | |
| timeout | No | Seconds 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_id | Yes | ID of the chart to export | |
| transparent | No | If true, exports with transparent background | |
| access_token | No | Optional Datawrapper API token. When provided, uses the caller's account. When omitted, falls back to the server's DATAWRAPPER_ACCESS_TOKEN env var. | |
| border_color | No | Color of the border, e.g., '#FFFFFF' (optional) | |
| border_width | No | Margin around visualization in pixels |
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.
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.
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.
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.
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.
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.
⚠️ DATAWRAPPER MCP TOOL ⚠️ This is part of the Datawrapper MCP server integration.
Get information about an existing Datawrapper chart, including its complete configuration, metadata, and URLs.
The returned configuration can be used to:
Understand how a chart is styled and configured
Adapt the configuration to a new dataset
Clone a chart's styling to create similar visualizations
Returns:
chart_id: The chart's unique identifier
title: Chart title
type: Simplified chart type name (bar, line, stacked_bar, etc.) - same format as used in list_chart_types and create_chart
config: Complete Pydantic model configuration including all styling, colors, axes, tooltips, annotations, and other properties
public_url: Public URL if published
edit_url: Editor URL
| Name | Required | Description | Default |
|---|---|---|---|
| chart_id | Yes | ID of the chart to retrieve | |
| access_token | No | Optional Datawrapper API token. When provided, uses the caller's account. When omitted, falls back to the server's DATAWRAPPER_ACCESS_TOKEN env var. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds little beyond that: it does not mention rate limits, permission/account requirements beyond what the schema says, or failure modes. It essentially restates that this is a non-mutating fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first two lines ('⚠️ DATAWRAPPER MCP TOOL ⚠️ / This is part of the Datawrapper MCP server integration. ---') are pure boilerplate that earn no place, and the entire 'Returns:' block duplicates the output schema. The genuinely useful purpose statement is buried below the noise rather than front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description needn't restate return fields — yet that is most of what it does. For a simple read-only get with rich annotations and full schema coverage, the minimum is met, but the description misses the one thing that would add value: disambiguating from siblings like get_chart_schema and update_chart.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (chart_id, access_token) are already documented in the schema, including the env-var fallback behavior. Baseline 3 applies since the description adds no syntax, format, or constraint detail beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get information about an existing Datawrapper chart') and enumerates what comes back (configuration, metadata, URLs). It is clear on its own, but never names or contrasts with siblings like get_chart_schema, so an agent can't tell from the text alone when this is the right fetch tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'returned configuration can be used to...' list implies downstream use cases (styling, adapting to a new dataset, cloning), which is helpful implied context. However there is no 'use this when X, use get_chart_schema when Y' guidance and no exclusions, so selection vs. alternatives is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ DATAWRAPPER MCP TOOL ⚠️ This is part of the Datawrapper MCP server integration.
Get the Pydantic JSON schema for a specific chart type. This is your primary tool for discovering styling and configuration options.
The schema shows:
All available properties and their types
Enum values (e.g., line widths, interpolation methods)
Default values
Detailed descriptions for each property
WORKFLOW: Use this tool first to explore options, then refer to https://datawrapper.readthedocs.io/en/latest/ for detailed examples and patterns showing how to use these properties in practice.
| Name | Required | Description | Default |
|---|---|---|---|
| chart_type | Yes | Chart type to get schema for |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value by enumerating what the schema exposes (types, enum values, defaults, descriptions) and clarifying the discovery workflow. Minor gap: no mention of output format/caching, but this is largely covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The workflow guidance is front-loaded well, but the tool description is padded with an unrelated banner ('⚠️ DATAWRAPPER MCP TOOL ⚠️ ... server integration') and a horizontal rule that add no selection value. The substantive content is efficient once past the boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only introspection tool with an output schema present, the description covers purpose, output contents, and next steps. Complete enough to call correctly; the only omission is pointing to the sibling list_chart_types for discovery of valid chart_type values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter is already documented. The description adds no syntax or format detail beyond 'chart type', which means it does not meaningfully extend the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the Pydantic JSON schema for a specific chart type') and explicitly positions itself as the primary discovery tool for styling/config options. This distinguishes it from list_chart_types and create_chart without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit workflow ('Use this tool first to explore options') and points to external docs for follow-up. It does not explicitly state when NOT to use it vs alternatives like list_chart_types, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ DATAWRAPPER MCP TOOL ⚠️ This is part of the Datawrapper MCP server integration.
List all available Datawrapper chart types with brief descriptions.
Use this tool to discover which chart types you can create. After choosing a type, use get_chart_schema(chart_type) to explore detailed configuration options.
Returns: List of available chart types with descriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered there. The description adds that the result is a list of chart types with brief descriptions, which is modest but real added context; it says nothing about ordering, pagination, or completeness of the list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening '⚠️ DATAWRAPPER MCP TOOL ⚠️ / This is part of the Datawrapper MCP server integration.' banner is pure boilerplate that delays the actual purpose. The remaining three sections (purpose, usage, returns) are lean and well organized, so the waste is confined to the header.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing the return value, and its 'Returns: List of available chart types with descriptions' plus the get_chart_schema handoff covers what an agent needs to proceed. Adding a note on whether the list is stable or ordered would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty, so there is no parameter semantics to explain. No missing parameter information creates ambiguity, and the description correctly does not invent any inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('List all available Datawrapper chart types') and immediately distinguishes it from the sibling get_chart_schema by framing this as the discovery step versus the configuration step. An agent can tell exactly what this returns without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the trigger ('Use this tool to discover which chart types you can create') and routes the agent explicitly to the correct follow-up ('use get_chart_schema(chart_type)'). No exclusions or negative conditions are given, but the when-to-use and next step are both clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ DATAWRAPPER MCP TOOL ⚠️ This is part of the Datawrapper MCP server integration.
Publish a Datawrapper chart to make it publicly accessible and render a preview in chat. IMPORTANT: Only use this tool when the user explicitly requests to publish the chart. Do not automatically publish charts after creation unless specifically asked.
| Name | Required | Description | Default |
|---|---|---|---|
| chart_id | Yes | ID of the chart to publish | |
| access_token | No | Optional Datawrapper API token. When provided, uses the caller's account. When omitted, falls back to the server's DATAWRAPPER_ACCESS_TOKEN env var. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the agent knows this is a safe, idempotent mutation. The description adds the consequential detail that publishing makes the chart 'publicly accessible', which is meaningful context beyond the annotations. However, it does not cover reversibility (can it be unpublished?), permission requirements, or what the preview response contains. Gaps remain but the key effect is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core content (purpose + usage warning) is tight and front-loaded after a distracting two-line banner. The '⚠️ DATAWRAPPER MCP TOOL ⚠️' header and horizontal rule add no semantic value and consume prime real estate. The useful sentences themselves are efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter publish tool with full schema coverage and no output schema, the description is nearly complete: it covers purpose, the critical usage constraint, and the public-accessibility effect. Minor gap: it doesn't mention how to undo publishing or what happens on repeated calls (though idempotentHint covers the latter).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (chart_id and access_token) are fully documented in the schema itself, including the fallback behavior for the token. The description adds no parameter-level meaning. Baseline 3 applies when the schema fully carries parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Publish a Datawrapper chart to make it publicly accessible and render a preview in chat.' This clearly distinguishes it from siblings like create_chart or update_chart. The surrounding banner header ('⚠️ DATAWRAPPER MCP TOOL ⚠️') is noise but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Only use this tool when the user explicitly requests to publish the chart. Do not automatically publish charts after creation unless specifically asked.' This is a rare, precise when/when-not directive that directly prevents a common failure mode (premature publishing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ DATAWRAPPER MCP TOOL ⚠️ This is part of the Datawrapper MCP server integration.
Update an existing Datawrapper chart's data or configuration using Pydantic models.
⚠️ IMPORTANT LIMITATION: You CANNOT change the chart type with this tool. Chart types are immutable once created. To change from one chart type to another (e.g., column → stacked_bar, or line → area), you must create a new chart instead.
WHAT YOU CAN UPDATE: • Chart data (add/modify/replace data points) • Title, intro, byline, source information • Colors, styling, axes configuration • Tooltips, annotations, labels • Any other configuration options for the existing chart type
WHAT YOU CANNOT UPDATE: ✗ Chart type (bar, line, column, etc.) - this is permanent
The chart_config must use high-level Pydantic fields only (title, intro, byline, source_name, source_url, etc.). Do NOT use low-level serialized structures like 'metadata', 'visualize', or other internal API fields.
STYLING UPDATES: Use get_chart_schema to see available fields, then apply styling changes:
Colors: {"color_category": {"sales": "#ff0000"}}
Line properties: {"lines": [{"column": "sales", "width": "style2"}]}
Axis settings: {"custom_range_y": [0, 200], "y_grid_format": "0,0"}
Tooltips: {"tooltip_number_format": "0.0"}
See https://datawrapper.readthedocs.io/en/latest/ for detailed examples. The provided config will be validated through Pydantic and merged with the existing chart configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | New chart data (optional). Same formats as create_chart. | |
| chart_id | Yes | ID of the chart to update | |
| access_token | No | Optional Datawrapper API token. When provided, uses the caller's account. When omitted, falls back to the server's DATAWRAPPER_ACCESS_TOKEN env var. | |
| chart_config | No | Updated chart configuration using high-level Pydantic fields (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: chart type is immutable, config is validated through Pydantic and merged with the existing configuration, and only high-level fields (not 'metadata'/'visualize') are accepted. The merge and immutability behaviors are exactly the traits an agent needs and annotations don't convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is dense and mostly earns its place, with limitations front-loaded. The banner header and the readthedocs link are marginal filler, but the bullets are functional rather than redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, limitations, parameter semantics, validation/merge behavior, and a documentation pointer. With annotations covering the safety profile and no output schema required, nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: chart_config must use high-level Pydantic fields and must not use low-level serialized structures, plus concrete styling examples that illustrate the expected shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Update an existing Datawrapper chart's data or configuration') with explicit scope: what can be updated (data, title, colors, axes) and what cannot (chart type). An agent can immediately distinguish this from create_chart and delete_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear routing rule for the main edge case: to change chart type you must use create_chart instead. It also points to get_chart_schema before styling updates. It doesn't give a general when-to-use-vs-sibling statement, but the exclusion path is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.4.0check_datawrapper_connectionexport_chart_png1 field changedInput schema / properties / timeoutAdded 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."
+}v0.1.0create_chartdelete_chartexport_chart_pngget_chartget_chart_schemalist_chart_typespublish_chartupdate_chartScored across 9 tools
Each tool has a distinct role in the Datawrapper lifecycle: discovery (list_chart_types, get_chart_schema), account check, create, publish, get, update, delete, and export. There is no meaningful overlap between chart creation, publishing, exporting, or schema exploration. The workflow order is made explicit in descriptions.
All tool names use snake_case with clear verb_noun patterns such as create_chart, get_chart, update_chart, delete_chart, publish_chart, and export_chart_png. The only slight variation is check_datawrapper_connection, but it still follows snake_case and remains readable. The set is highly predictable.
Nine tools is well-scoped for a chart creation and management integration. Each tool covers a necessary operation without obvious redundancy. The count stays comfortably within the ideal 3-15 range.
Core chart lifecycle operations are covered: creation, retrieval, update, deletion, publishing, export, schema discovery, and connection checking. The main gap is the lack of a list_charts or search tool for finding existing chart IDs, which would help agents manage prior work. This is a minor gap that can be worked around when chart IDs are known.
Create, inspect, manage, and render charts and data visualizations as SVG/PNG or interactive embeds.
Renders interactive Chart.js charts and dashboards inline in AI conversations.
Charts and tables for AI agents with live-updating embed links. No account: signup returns a key.
Renders interactive Chart.js charts and dashboards inline in AI conversations. Supports bar, line, area, pie, doughnut, scatter, and radar charts with multi-chart dashboard grids.