Skip to main content
Glama
hqu

Datawrapper MCP

by hqu

export_chart_png

Export Datawrapper charts as PNG images with customizable dimensions, resolution, transparency, and borders for display or download.

Instructions

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


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

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chart_idYes
widthNo
heightNo
plainNo
zoomNo
transparentNo
border_widthNo
border_colorNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler logic for the `export_chart_png` tool, which takes chart ID and export parameters, generates the PNG, and encodes it as base64 for MCP response.
    async def export_chart_png(arguments: ExportChartPngArgs) -> list[ImageContent]:
        """Export a chart as PNG and return it as inline image."""
        chart_id = arguments["chart_id"]
    
        # Build export parameters
        export_params: dict[str, Any] = {}
        if "width" in arguments:
            export_params["width"] = arguments["width"]
        if "height" in arguments:
            export_params["height"] = arguments["height"]
        if "plain" in arguments:
            export_params["plain"] = arguments["plain"]
        if "zoom" in arguments:
            export_params["zoom"] = arguments["zoom"]
        if "transparent" in arguments:
            export_params["transparent"] = arguments["transparent"]
        if "border_width" in arguments:
            border_width = arguments["border_width"]
            assert isinstance(border_width, int)
            export_params["border_width"] = border_width
        if "border_color" in arguments:
            export_params["border_color"] = arguments["border_color"]
    
        # Get chart using factory function
        chart = get_chart(chart_id)
    
        # Export PNG using Pydantic instance method
        png_bytes = chart.export_png(**cast(dict[str, Any], export_params))
    
        # Encode to base64
        base64_data = base64.b64encode(png_bytes).decode("utf-8")
    
        return [
            ImageContent(
                type="image",
                data=base64_data,
                mimeType="image/png",
            )
        ]
  • Input argument schema for the `export_chart_png` tool.
    class ExportChartPngArgs(TypedDict):
        """Arguments for export_chart_png handler."""
    
        chart_id: str
        width: NotRequired[int]
        height: NotRequired[int]
        plain: NotRequired[bool]
        zoom: NotRequired[int]
        transparent: NotRequired[bool]
        border_width: NotRequired[int]
        border_color: NotRequired[str]
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.

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

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