Skip to main content
Glama
hqu

Datawrapper MCP

by hqu

get_chart

Retrieve complete configuration and metadata for existing Datawrapper charts to understand styling, adapt to new datasets, or clone visualizations.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chart_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The `get_chart_info` function is the handler that implements the logic for "get_chart". It retrieves chart information using the `get_chart` factory function, processes the configuration, and returns the result as `TextContent`.
    async def get_chart_info(arguments: GetChartArgs) -> list[TextContent]:
        """Get information about an existing chart including complete configuration."""
        chart_id = arguments["chart_id"]
    
        # Get chart using factory function
        chart = get_chart(chart_id)
    
        # Get the complete config
        config = chart.model_dump()
    
        # Convert DataFrame to list of records if data exists
        if config.get("data") is not None and hasattr(config["data"], "to_dict"):
            config["data"] = config["data"].to_dict(orient="records")
    
        # Convert API type to simplified name for consistency with list_chart_types
        simplified_type = API_TYPE_TO_SIMPLIFIED.get(chart.chart_type, chart.chart_type)
    
        result = {
            "chart_id": chart.chart_id,
            "title": chart.title,
            "type": simplified_type,
            "config": config,
            "public_url": chart.get_public_url(),
            "edit_url": chart.get_editor_url(),
        }
    
        return [TextContent(type="text", text=json.dumps(result, indent=2))]
  • `GetChartArgs` defines the input schema for the `get_chart` tool handler.
    class GetChartArgs(TypedDict):
        """Arguments for get_chart handler."""
    
        chart_id: 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 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.

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