Skip to main content
Glama
palewire

datawrapper-mcp

by palewire

create_chart

Build Datawrapper charts with detailed customization. Pass data in JSON, select a chart type, and control all visual properties through a Pydantic configuration.

Instructions

⚠️ 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:

  1. Basic chart with title: chart_config = { "title": "Monthly Sales", "intro": "Sales data for Q1 2024" }

  2. Chart with custom colors: chart_config = { "title": "Product Comparison", "color_category": { "Product A": "#1f77b4", "Product B": "#ff7f0e" } }

  3. Styled line chart: chart_config = { "title": "Sales Trends", "lines": [ {"column": "sales", "width": "style2", "interpolation": "curved"} ], "custom_range_y": [0, 1000] }

STYLING WORKFLOW:

  1. Use list_chart_types to see available chart types

  2. Use get_chart_schema to explore all options for your chosen type

  3. Refer to https://datawrapper.readthedocs.io/en/latest/ for detailed examples

  4. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesChart 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_typeYesType 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
chart_configYesComplete chart configuration as a Pydantic model dict
access_tokenNoOptional 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.
Behavior5/5

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

Annotations show readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description confirms this is a creation tool (not read-only, not destructive), and it details the behavior: creates a chart, uses provided data and config, handles tokens. It adds context beyond annotations (e.g., how to handle large datasets, preference for inline data). No contradictions.

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 long but well-structured with sections (warning, intro, best practices, examples, workflow, common patterns). It is front-loaded with the crucial warning and purpose. While every section adds value, some parts (like the DO NOT list and the note about automatic scaling) could be slightly condensed without losing effectiveness. However, it remains clear and organized.

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

Completeness5/5

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

Given the tool's complexity (chart creation with many options), the description is comprehensive. It covers: purpose, prohibited alternatives, data format preferences, parameter usage (data, chart_type, chart_config, access_token), best practices, a step-by-step workflow, and detailed examples. The sibling tools are mentioned in the workflow. No output schema exists, but the description adequately hints at the action (chart creation) – the agent can infer that a chart object is returned. Overall, the description fully compensates for the lack of an output schema.

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

Parameters5/5

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

Input schema has 100% coverage with detailed descriptions. The description adds significant additional value: preferred data formats with examples, alt format for large datasets, instructs to use list_chart_types for chart_type, and explains chart_config as a Pydantic model dict with examples. This goes well beyond the schema's 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 'Create a Datawrapper chart' and emphasizes this is the complete Datawrapper integration. It distinguishes from sibling tools like list_chart_types, get_chart_schema by providing a workflow reference and explicitly warning against using other methods (e.g., 'DO NOT install the datawrapper Python package'). The verb-resource combo is specific and unambiguous.

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 provides explicit when-to-use guidance ('Use this MCP tool for ALL Datawrapper chart creation') and what not to do (DO NOT list). It includes best practices (start simple, let Datawrapper handle scaling), a styling workflow (list_chart_types → get_chart_schema → build config), and references to external documentation. This gives the agent clear decision support.

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

Install Server

Other Tools

Latest Blog Posts

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/palewire/datawrapper-mcp'

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