How do I use Datawrapper 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., "@Datawrapper MCP Create a line chart showing 2023 sales data and publish it" 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.

Datawrapper MCP

by hqu

Overview Schema Related Servers Score Discussions

Python

A Model Context Protocol (MCP) server that enables AI assistants to create Datawrapper charts. Built on the datawrapper Python library with Pydantic validation.

Example Usage

Here's a 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: Metabase MCP Plus

Getting Started

Requirements

A Datawrapper account (sign up at https://datawrapper.de/signup/)
An MCP client such as Claude or OpenAI Codex
Python 3.10 or higher
A Python package installer such as pip or uvx

Get Your API Token

Go to https://app.datawrapper.de/account/api-tokens
Create a new API token
Add it to your MCP configuration as shown below

Installation

Claude Code

Using uvx (recommended)

Configure your MCP client in claude_desktop_config.json:

{
  "mcpServers": {
    "datawrapper": {
      "command": "uvx",
      "args": ["datawrapper-mcp"],
      "env": {
        "DATAWRAPPER_ACCESS_TOKEN": "your-token-here"
      }
    }
  }
}

Using pip

First install the package:

pip install datawrapper-mcp

Then configure your MCP client in claude_desktop_config.json:

{
  "mcpServers": {
    "datawrapper": {
      "command": "datawrapper-mcp",
      "env": {
        "DATAWRAPPER_ACCESS_TOKEN": "your-token-here"
      }
    }
  }
}

OpenAI Codex

CLI with uvx

Add this to ~/.codex/config.toml:

[mcp_servers.datawrapper]
args = ["datawrapper-mcp"]
command = "uvx"
startup_timeout_sec = 30

[mcp_servers.datawrapper.env]
DATAWRAPPER_ACCESS_TOKEN = "your-token-here"

CLI with pip

First install the package:

pip install datawrapper-mcp

Then add this to ~/.codex/config.toml:

[mcp_servers.datawrapper]
command = "datawrapper-mcp"
startup_timeout_sec = 30

[mcp_servers.datawrapper.env]
DATAWRAPPER_ACCESS_TOKEN = "your-token-here"

Secure secrets

For enhanced security, you can configure a pass-through environment variable by ensuring that DATAWRAPPER_ACCESS_TOKEN is set in your environment, and replacing this in your config.toml:

[mcp_servers.datawrapper.env]
DATAWRAPPER_ACCESS_TOKEN = "your-token-here"

With this:

env_vars = ["DATAWRAPPER_ACCESS_TOKEN"]

This ensures that the value set for DATAWRAPPER_ACCESS_TOKEN in your environment is passed through to Codex without having to store the secret as text in a config file.

Desktop application

If you're using the Codex Desktop Application, you can set up the MCP in your settings under MCP servers:

Under Custom servers, click Add server
Under Name, enter datawrapper-mcp
Select STDIO
Under Command to launch, type uvx (you must have uv installed)
Under Arguments, add datawrapper-mcp
Under Environment variables, add DATAWRAPPER_ACCESS_TOKEN as the key and your token as the value
Click Save

Kubernetes Deployment

For enterprise deployments, this server can be deployed to Kubernetes using HTTP transport:

Building the Docker Image

docker build -t datawrapper-mcp:latest .

Running with Docker

docker run -p 8501:8501 \
  -e DATAWRAPPER_ACCESS_TOKEN=your-token-here \
  -e MCP_SERVER_HOST=0.0.0.0 \
  -e MCP_SERVER_PORT=8501 \
  datawrapper-mcp:latest

Environment Variables

DATAWRAPPER_ACCESS_TOKEN: Your Datawrapper API token (required)
MCP_SERVER_HOST: Server host (default: 0.0.0.0)
MCP_SERVER_PORT: Server port (default: 8501)
MCP_SERVER_NAME: Server name (default: datawrapper-mcp)

Health Check Endpoint

The HTTP server includes a /healthz endpoint for Kubernetes liveness and readiness probes:

curl http://localhost:8501/healthz
# Returns: {"status": "healthy", "service": "datawrapper-mcp"}

Kubernetes Configuration Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: datawrapper-mcp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: datawrapper-mcp
  template:
    metadata:
      labels:
        app: datawrapper-mcp
    spec:
      containers:
      - name: datawrapper-mcp
        image: datawrapper-mcp:latest
        ports:
        - containerPort: 8501
        env:
        - name: DATAWRAPPER_ACCESS_TOKEN
          valueFrom:
            secretKeyRef:
              name: datawrapper-secrets
              key: access-token
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8501
          initialDelaySeconds: 5
          periodSeconds: 30
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8501
          initialDelaySeconds: 5
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: datawrapper-mcp
spec:
  selector:
    app: datawrapper-mcp
  ports:
  - protocol: TCP
    port: 8501
    targetPort: 8501

Available Tools

8 tools

create_chartA

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

Args: data: 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: 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 chart_config: Complete chart configuration as a Pydantic model dict

Returns: Chart ID and editor URL

ParametersJSON Schema

Name	Required	Description	Default
`data`	Yes
`chart_type`	Yes
`chart_config`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It does an excellent job describing workflow patterns, best practices, and constraints (e.g., 'Let Datawrapper handle axis scaling automatically unless there's a specific reason to override'). It explains the return format ('Chart ID and editor URL') and provides extensive examples. The only minor gap is explicit mention of authentication requirements or rate limits.

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 description is comprehensive but lengthy (over 700 words). While well-structured with clear sections (warning, purpose, best practices, examples, workflow, parameter details), it could be more front-loaded. The core purpose appears after the warning section, and some examples could be streamlined. Every sentence adds value, but the overall length reduces conciseness.

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 complexity (3 parameters with nested objects, 0% schema coverage, no annotations, but with output schema), the description is exceptionally complete. It covers purpose, usage guidelines, parameter semantics, workflow patterns, examples, and return values. The output schema exists, so the description appropriately focuses on explaining parameters and behavior rather than return format details.

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?

With 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all three parameters. For 'data', it explains recommended formats, preferred order, and alternative approaches. For 'chart_type', it references sibling tools and provides common examples. For 'chart_config', it explains this should be 'a complete Pydantic model dict' and provides extensive examples and styling patterns.

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: 'Create a Datawrapper chart with full control using Pydantic models.' It specifies the verb ('Create'), resource ('Datawrapper chart'), and scope ('full control'), distinguishing it from siblings like update_chart or delete_chart. The initial warning section reinforces this is the primary creation tool for Datawrapper integration.

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 guidance on when to use this tool versus alternatives. It starts with a strong directive: 'Use this MCP tool for ALL Datawrapper chart creation' and lists specific alternatives to avoid (Python package, direct API). It also references sibling tools like list_chart_types and get_chart_schema for preparatory work, and mentions styling workflows that guide when to apply customization.

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

delete_chartA

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

Delete a Datawrapper chart permanently.

Args: chart_id: ID of the chart to delete

Returns: Confirmation message

ParametersJSON Schema

Name	Required	Description	Default
`chart_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/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 clearly indicates this is a destructive operation ('Delete... permanently'), which is critical context. However, it lacks details on permissions, error conditions, or irreversible consequences beyond deletion. It adds some value but not comprehensive behavioral context.

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 appropriately sized and front-loaded, with the core purpose stated first. The header and separator are slightly verbose but not excessive. The Args and Returns sections are structured clearly, though the header could be more concise.

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

Completeness4/5

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

Given the tool's complexity (destructive operation), no annotations, and an output schema exists (returns confirmation message), the description is reasonably complete. It covers the action, parameter, and return, but could improve with more behavioral details (e.g., permissions, side effects) to fully compensate for the lack of annotations.

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 0%, so the description must compensate. It documents the single parameter ('chart_id: ID of the chart to delete'), adding meaning beyond the schema's basic title. However, it does not explain format, validation, or sourcing of the ID, leaving gaps in 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 specific action ('Delete a Datawrapper chart permanently') with the resource ('Datawrapper chart'), distinguishing it from sibling tools like 'create_chart', 'update_chart', or 'get_chart'. The purpose is unambiguous and directly addresses what the tool does.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing the chart ID), exclusions (e.g., not for published charts), or comparisons to siblings like 'update_chart' or 'publish_chart'. Usage is implied but not explicitly stated.

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

export_chart_pngA

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

Args: chart_id: ID of the chart to export width: Width of the image in pixels (optional) height: Height of the image in pixels (optional) plain: If true, exports only the visualization without header/footer zoom: Scale multiplier for resolution, e.g., 2 = 2x resolution transparent: If true, exports with transparent background border_width: Margin around visualization in pixels border_color: Color of the border, e.g., '#FFFFFF' (optional)

Returns: PNG image content

ParametersJSON Schema

Name	Required	Description	Default
`chart_id`	Yes
`width`	No
`height`	No
`plain`	No
`zoom`	No
`transparent`	No
`border_width`	No
`border_color`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/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 effectively describes key behaviors: it's a read/export operation (implied by 'export'), requires a pre-existing chart, supports high-resolution output, and returns PNG content. It doesn't mention rate limits, authentication needs, or error conditions, but covers the core operational behavior well.

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 well-structured with clear sections (warning header, purpose statement, usage guidelines, parameter explanations, return value). While slightly longer due to the detailed parameter section, every sentence earns its place by providing essential information. The front-loaded purpose and usage guidelines are immediately clear.

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

Completeness4/5

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

Given the tool's complexity (8 parameters, export operation) and the presence of an output schema (which handles return value documentation), the description provides good completeness. It covers purpose, usage constraints, parameter semantics, and behavioral context. It doesn't explain error cases or authentication requirements, but with an output schema and detailed parameter explanations, it's mostly complete.

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 0% schema description coverage, the description compensates by providing a detailed parameter section that explains all 8 parameters with clear semantic meaning beyond just their names. It explains what each parameter controls (e.g., 'Scale multiplier for resolution', 'Margin around visualization'), though it doesn't specify value ranges or constraints. This significantly adds value over the bare schema.

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 specific action ('Export a Datawrapper chart as PNG and display it inline'), identifies the resource ('Datawrapper chart'), and distinguishes it from siblings by mentioning it requires a chart created first using create_chart. It goes beyond just restating the name by specifying the output format and display method.

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 guidance on when to use ('Only use this tool when the user explicitly requests to see the chart image or export it as PNG') and when not to use ('Do not automatically export charts after creation unless specifically asked'). It also references the prerequisite sibling tool ('The chart must be created first using create_chart'), offering clear alternatives and context.

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

get_chartA

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

Args: chart_id: ID of the chart to retrieve

Returns: Chart information including complete configuration and URLs

ParametersJSON Schema

Name	Required	Description	Default
`chart_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/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 effectively describes the tool's behavior: it retrieves comprehensive chart data, including configuration and URLs, and outlines potential use cases (e.g., understanding styling, adapting configuration, cloning styling). It does not mention permissions, rate limits, or error handling, but covers core functionality well for a read operation.

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 description is appropriately sized and front-loaded with the core purpose. However, it includes redundant sections: the 'Returns:' and 'Args:' lists repeat information already stated in the body, and the '⚠️ DATAWRAPPER MCP TOOL ⚠️' header is unnecessary clutter. Some sentences could be more streamlined.

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 low complexity (one parameter), lack of annotations, and presence of an output schema (which handles return values), the description is complete enough. It covers purpose, usage context, parameter meaning, and behavioral aspects without needing to detail output structure, making it adequate for the agent's needs.

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?

The input schema has 0% description coverage, but the description compensates by explaining the single parameter: 'chart_id: ID of the chart to retrieve.' This adds clear meaning beyond the schema's basic type information. For a tool with only one parameter, this is sufficient to achieve a high score, though it doesn't detail format constraints or examples.

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: 'Get information about an existing Datawrapper chart, including its complete configuration, metadata, and URLs.' It specifies the verb ('Get'), resource ('Datawrapper chart'), and scope ('complete configuration, metadata, and URLs'), distinguishing it from siblings like create_chart, delete_chart, or update_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 description provides clear context for when to use this tool: to retrieve information about an existing chart. It implicitly contrasts with siblings by focusing on retrieval rather than creation, deletion, or modification. However, it does not explicitly state when NOT to use it or name specific alternatives for overlapping use cases.

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

get_chart_schemaA

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

Args: chart_type: Chart type to get schema for

Returns: JSON schema for the chart type

ParametersJSON Schema

Name	Required	Description	Default
`chart_type`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/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 that the tool returns a JSON schema with details like properties, types, enums, defaults, and descriptions, which helps the agent understand the output format. However, it doesn't mention potential errors (e.g., invalid chart types), rate limits, or authentication needs, leaving some behavioral gaps. No contradiction with annotations exists.

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 well-structured with sections (e.g., workflow, args, returns) and uses bullet points for clarity. It's front-loaded with the core purpose. However, the warning banner and markdown formatting add some verbosity that isn't strictly necessary, slightly reducing efficiency. Overall, most sentences earn their place by providing useful information.

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 low complexity (1 parameter), no annotations, and the presence of an output schema (which handles return values), the description is complete enough. It covers purpose, usage guidelines, parameter semantics, and output expectations. The reference to external documentation adds extra context, making it suitable for an agent to invoke the tool correctly without gaps.

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?

The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'chart_type' is used to 'get schema for a specific chart type,' implying it's an identifier for chart types (e.g., 'line', 'bar'). While it doesn't list possible values or formats, it clarifies the parameter's role beyond the basic schema. With only one parameter, this is sufficient for a high score.

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: 'Get the Pydantic JSON schema for a specific chart type.' It specifies the verb ('Get') and resource ('Pydantic JSON schema'), and distinguishes it from siblings like 'create_chart' or 'update_chart' by focusing on schema discovery rather than chart manipulation. The mention of 'primary tool for discovering styling and configuration options' further clarifies its exploratory role.

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 usage guidance: 'Use this tool first to explore options,' indicating it should be used before other tools like 'create_chart' or 'update_chart.' It also references an external resource ('https://datawrapper.readthedocs.io/') for detailed examples, offering a clear workflow. This effectively distinguishes when to use this tool versus alternatives in the sibling list.

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

list_chart_typesA

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

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/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 full burden. It discloses that this is a read operation (listing), mentions it's part of Datawrapper MCP integration, and describes the return format ('List of available chart types with descriptions'). However, it doesn't mention potential limitations like rate limits or authentication requirements.

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?

Well-structured with clear sections: warning banner, purpose statement, usage guidance, and return description. The warning banner adds context but isn't strictly necessary for tool understanding. The core information is front-loaded and efficiently presented.

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?

Complete for a parameterless discovery tool. The description explains purpose, usage context, and output format. With an output schema available, the description doesn't need to detail return values further. It provides all necessary context for an agent to understand when and how to use this 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?

The tool has 0 parameters, and schema description coverage is 100%. The description appropriately doesn't discuss parameters since none exist. It focuses instead on the tool's purpose and output, which is appropriate for a parameterless tool.

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 specific verb ('List') and resource ('all available Datawrapper chart types with brief descriptions'). It distinguishes from siblings by focusing on discovery rather than creation, deletion, or modification of charts.

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?

Explicit guidance is provided: 'Use this tool to discover which chart types you can create' and 'After choosing a type, use get_chart_schema(chart_type) to explore detailed configuration options.' This clearly indicates when to use this tool versus the sibling get_chart_schema tool.

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

publish_chartA

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

Publish a Datawrapper chart to make it publicly accessible. Returns the public URL of the published chart. IMPORTANT: Only use this tool when the user explicitly requests to publish the chart. Do not automatically publish charts after creation unless specifically asked.

Args: chart_id: ID of the chart to publish

Returns: Public URL of the published chart

ParametersJSON Schema

Name	Required	Description	Default
`chart_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/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 effectively describes key behaviors: it makes charts publicly accessible (implying a mutation/permissions change), returns a public URL, and includes a warning about explicit user requests. However, it lacks details on potential side effects like irreversible changes or authentication requirements.

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 appropriately sized and front-loaded, with the core purpose stated first. However, the initial warning banner ('⚠️ DATAWRAPPER MCP TOOL ⚠️') and separator ('---') add minor clutter without critical information, slightly reducing efficiency.

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 moderate complexity (1 parameter, mutation operation), no annotations, and an output schema present (which handles return values), the description is complete enough. It covers purpose, usage guidelines, parameter meaning, and key behavioral aspects, providing adequate context for an agent to use 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?

The schema description coverage is 0%, so the description must compensate. It clearly explains the single parameter 'chart_id' as 'ID of the chart to publish', adding essential meaning beyond the schema's basic type information. This is sufficient for the single parameter, though it doesn't cover format or validation details.

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 specific action ('Publish a Datawrapper chart') and the resource ('Datawrapper chart'), distinguishing it from siblings like create_chart, delete_chart, or update_chart by focusing on making charts publicly accessible rather than creating, removing, or modifying them.

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 provides explicit guidance on when to use this tool ('when the user explicitly requests to publish the chart') and when not to use it ('Do not automatically publish charts after creation unless specifically asked'), clearly differentiating it from alternatives like create_chart or update_chart that might be used in other contexts.

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

update_chartA

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

Args: chart_id: ID of the chart to update data: New chart data (optional). Same formats as create_chart. chart_config: Updated chart configuration using high-level Pydantic fields (optional)

Returns: Confirmation message with editor URL

ParametersJSON Schema

Name	Required	Description	Default
`chart_id`	Yes
`data`	No
`chart_config`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/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 does an excellent job describing limitations (chart type immutability), what can and cannot be updated, validation behavior (Pydantic validation), and merge behavior (config merged with existing). It also mentions the return format (confirmation message with editor URL). The only minor gap is no mention of authentication requirements or rate limits.

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 description is comprehensive but lengthy (over 400 words). While most content is valuable, some sections like the styling examples and documentation link could be more concise. The information is well-structured with clear sections, but it's not optimally front-loaded for quick scanning.

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 (mutation operation with 3 parameters, no annotations, but with output schema), the description is remarkably complete. It covers purpose, limitations, usage guidelines, parameter semantics, behavioral details, and references to other tools. The output schema handles return values, so the description appropriately focuses on everything else the agent needs to know.

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 0% schema description coverage, the description must compensate for all three parameters. It clearly explains chart_id ('ID of the chart to update'), data ('New chart data (optional). Same formats as create_chart'), and chart_config ('Updated chart configuration using high-level Pydantic fields (optional)'). It provides formatting guidance and examples for chart_config, though more detail on data formats would be helpful.

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: 'Update an existing Datawrapper chart's data or configuration using Pydantic models.' It specifies the verb ('update'), resource ('existing Datawrapper chart'), and scope ('data or configuration'), and distinguishes it from sibling tools like create_chart by emphasizing it's for existing charts only.

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 usage guidelines: it states when to use this tool (for updating existing charts) and when not to use it (cannot change chart type, must use create_chart instead). It also mentions get_chart_schema as a reference for available fields, giving clear alternatives and prerequisites.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0Mar 22, 2026
- First observedcreate_chart
- First observeddelete_chart
- First observedexport_chart_png
- First observedget_chart
- First observedget_chart_schema
- First observedlist_chart_types
- First observedpublish_chart
- First observedupdate_chart

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a distinct, well-defined purpose with no overlap. For example, create_chart, get_chart, update_chart, and delete_chart handle different CRUD operations, while list_chart_types, get_chart_schema, publish_chart, and export_chart_png serve unique auxiliary functions. The descriptions clearly differentiate their roles, eliminating any confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as create_chart, delete_chart, and export_chart_png. This uniformity makes the set predictable and easy to navigate, with no deviations in naming conventions across the eight tools.

Tool Count5/5

With 8 tools, the server is well-scoped for Datawrapper chart management. It covers essential operations like creation, retrieval, updating, deletion, listing, schema exploration, publishing, and exporting, providing a comprehensive yet focused toolset without being overly sparse or bloated.

Completeness5/5

The toolset offers complete coverage for the Datawrapper chart domain, including full CRUD operations (create_chart, get_chart, update_chart, delete_chart), lifecycle management (publish_chart), schema discovery (list_chart_types, get_chart_schema), and output handling (export_chart_png). There are no apparent gaps that would hinder an agent's workflow.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

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

ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
Danushkumar-V-mcp-discordOAuth
ai.smithery
An MCP server that integrates with Discord to provide AI-powered features.
Communication Social Media App Automation
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
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

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
Metabase MCP Plus
Databases Data Visualization Search
schachan
A
license
A
quality
C
maintenance
An MCP server that enables AI assistants to query databases, execute SQL, and manage Metabase resources like dashboards, cards, and collections through natural language.
Updated 6 months ago (2026-03-20 01:45 UTC)
22
MIT
holoviz-viz-mcp
Data Visualization Research & Data
ghostiee-11
A
license
A
quality
D
maintenance
An MCP server that enables AI assistants to create interactive visualizations, perform statistical analysis, run auto-EDA, and build dashboards using the HoloViz ecosystem with self-contained HTML output.
Updated 6 months ago (2026-03-08 06:24 UTC)
36
MIT
nveilofficial
Data Visualization AI & Machine Learning
nveil-ai
A
license
Not graded
quality
C
maintenance
AI-powered data visualization MCP server that generates publication-ready charts from natural language descriptions while keeping data local.
Updated 3 months ago (2026-06-05 14:26 UTC)
3
AGPL 3.0

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

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

Example Usage

Getting Started

Requirements

Get Your API Token

Installation

Claude Code

OpenAI Codex

Kubernetes Deployment

Building the Docker Image

Running with Docker

Environment Variables

Health Check Endpoint

Kubernetes Configuration Example

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

nveilofficial

Latest Blog Posts

MCP directory API