Loading ToolBench
A Model Context Protocol (MCP) server for creating, updating, publishing, and managing Datawrapper charts using AI assistants
The Datawrapper MCP server demonstrates solid definition quality with well-structured tool names, clear descriptions for most tools, and explicit input schemas. However, there are notable gaps in parameter descriptions, output schema documentation, and error handling guidance. The server follows verb-noun naming conventions consistently (list_chart_types, get_chart_schema, create_chart, etc.) and uses proper JSON Schema for input validation. Most tools have descriptions in the 100-300 character range, which is appropriate. The main weaknesses are: (1) several tools lack explicit descriptions for all parameters (e.g., update_chart's 'data' parameter has minimal guidance), (2) no documented output schemas or return types visible in the tool definitions, (3) missing error handling and recovery guidance in tool descriptions, and (4) no acknowledgment of idempotency guarantees or side effects in WRITE operations.
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. Args: access_token: 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). Returns: The authenticated account's email, name, and ID as JSON, or a troubleshooting-oriented error if the token was rejected.
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
update_chart, publish_chart, get_chart, and delete_chart have minimal descriptions (under 100 chars). These are critical state-modification and retrieval operations that need explicit guidance on when to call them, what they modify, and what side effects occur.
No tool descriptions explicitly document output schemas or return types. The rubric requires documentation of what fields the LLM can expect from each tool's response so it can plan downstream calls and extract data correctly.
Destructive operations (delete_chart) and state-modifying operations (create_chart, update_chart, publish_chart) lack explicit confirmation steps, dry-run support, or idempotency guarantees in their descriptions. The rubric pattern:confirmation-request requires acknowledgment of side effects for irreversible operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Delete a chart permanently.
Export a chart as a PNG image file.
Get complete information about an existing chart including its configuration and data.
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
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
Publish a chart to make it publicly accessible.
Update an existing chart's data and/or configuration properties.
Parameter descriptions for update_chart, publish_chart, get_chart, and delete_chart are sparse or absent. The 'data' param in update_chart says 'Optional new data for the chart' but doesn't explain format (CSV, JSON, list) or whether it replaces or merges existing data.
All tools accept optional 'access_token' parameter, exposing credentials as a tool parameter. The rubric pattern:secret-injection requires credentials to use server-side injection via environment variables or vault, not tool params. Agent traces log all parameters, secrets in params leak into logs and prompt history.
No error handling guidance in tool descriptions. Tools should document retryable vs. fatal errors and suggest recovery steps. E.g., 'If chart_id not found, try searching recent charts' or 'If export timeout, increase timeout parameter and retry.'
create_chart accepts 'chart_config' as 'object | string'. The dual type is ambiguous, when should it be a string vs object? The description says 'complete Pydantic model dict' but doesn't clarify the string variant or when to use it.
export_chart_png has many optional numeric parameters (width, height, zoom, timeout, border_width) with no min/max constraints documented. The rubric requires explicit bounds (e.g., 'width: 100-4000 pixels', 'timeout: 5-300 seconds') to prevent agents from passing absurd values.
No tools explicitly declare their permissions (e.g., 'read:charts', 'write:charts', 'delete:charts'). The rubric pattern:scope-declaration requires tools to declare required permissions for least-privilege agent configuration and audit trails.