Skip to main content
Glama
MR901

mcp-plots

by MR901

PyPI PyPI Downloads Smithery Glama Python Versions License

Why MCP Plots?

  • Instant, visual-first charts using Mermaid (renders directly in MCP clients like Cursor)

  • Simple prompts to generate charts from plain data

  • Zero-setup options via uvx, or install from PyPI/Docker

  • Flexible output formats: mermaid (default), PNG image, or text

Related MCP server: PlotMCP Server

Quick Usage

  • Ask your MCP client: "Create a bar chart showing sales: A=100, B=150, C=80"

  • Default output is Mermaid, so diagrams render instantly in Cursor

Quick Start

pip install mcp-plots
mcp-plots  # Start the server

For Cursor Users

  1. Install the package: pip install mcp-plots

  2. Add to your Cursor MCP config (~/.cursor/mcp.json):

    {
      "mcpServers": {
        "plots": {
          "command": "mcp-plots",
          "args": ["--transport", "stdio"]
        }
      }
    }

    Alternative (zero-install via uvx + PyPI):

    {
      "mcpServers": {
        "plots": {
          "command": "uvx",
          "args": ["mcp-plots", "--transport", "stdio"]
        }
      }
    }
  3. Restart Cursor

  4. Ask: "Create a bar chart showing sales: A=100, B=150, C=80"

Development Installation

uvx --from git+https://github.com/mr901/mcp-plots.git run-server.py

Documentation → | Quick Start → | API Reference →

MCP Registry

This server is published under the MCP registry identifier io.github.MR901/mcp-plots. You can discover/verify it via the official registry API:

curl "https://registry.modelcontextprotocol.io/v0/servers?search=io.github.MR901/mcp-plots"

Registry metadata for this project is tracked in server.json.

Install with Smithery

This repository includes a smithery.yaml for easy setup with Smithery.

Example install using the Smithery CLI (adjust --client as needed, e.g. cursor, claude):

npx -y @smithery/cli install \
  https://raw.githubusercontent.com/mr901/mcp-plots/main/smithery.yaml \
  --client cursor

After installation, your MCP client should be able to start the server over stdio using the command defined in smithery.yaml.

Project layout

src/
  app/                # Server construction and runtime
    server.py
  capabilities/       # MCP tools and prompts
    tools.py
    prompts.py
  visualization/      # Plotting engines and configurations
    chart_config.py
    generator.py

Requirements

  • Python 3.10+

  • See requirements.txt

Setup Routes

The easiest way to run the MCP server without managing Python environments:

# Run directly with uvx (no installation needed)
uvx --from git+https://github.com/mr901/mcp-plots.git run-server.py

# Or install and run the command
uvx --from git+https://github.com/mr901/mcp-plots.git mcp-plots

# With custom options
uvx --from git+https://github.com/mr901/mcp-plots.git mcp-plots --port 8080 --log-level DEBUG

Why uvx?

  • No Environment Management: Automatically handles Python dependencies

  • Isolated Execution: Runs in its own virtual environment

  • Always Latest: Pulls fresh code from repository

  • Zero Setup: Works immediately without pip install

  • Cross-Platform: Same command works on Windows, macOS, Linux

PyPI (Traditional Installation)

  1. Install dependencies

pip install -r requirements.txt
  1. Run the server (HTTP transport, default port 8000)

python -m src --transport streamable-http --host 0.0.0.0 --port 8000 --log-level INFO
  1. Run with stdio (for MCP clients that spawn processes)

python -m src --transport stdio

Local Development (from source)

git clone https://github.com/mr901/mcp-plots.git
cd mcp-plots
pip install -e .
python -m src --transport stdio --log-level DEBUG

Docker

docker build -t mcp-plots .
docker run -p 8000:8000 mcp-plots

Environment variables (optional):

  • MCP_TRANSPORT (streamable-http|stdio)

  • MCP_HOST (default 0.0.0.0)

  • MCP_PORT (default 8000)

  • LOG_LEVEL (default INFO)

Tools

  • list_chart_types() → returns available chart types

  • list_themes() → returns available themes

  • suggest_fields(sample_rows) → suggests field roles based on data samples

  • render_chart(chart_type, data, field_map, config_overrides?, options?, output_format?) → returns MCP content

  • generate_test_image() → generates a test image (red circle) to verify MCP image support

Cursor Integration

This MCP server is fully compatible with Cursor's image support! When you use the render_chart tool:

  • Charts appear directly in chat - No need to save files or open separate windows

  • AI can analyze your charts - Vision-enabled models can discuss and interpret your visualizations

  • Perfect MCP format - Uses the exact base64 PNG format that Cursor expects

The server returns images in the MCP format Cursor requires:

{
  "content": [
    {
      "type": "image", 
      "data": "<base64-encoded-png>",
      "mimeType": "image/png"
    }
  ]
}

Example call (pseudo):

render_chart(
  chart_type="bar",
  data=[{"category":"A","value":10},{"category":"B","value":20}],
  field_map={"category_field":"category","value_field":"value"},
  config_overrides={"title":"Example Bar","width":800,"height":600,"output_format":"MCP_IMAGE"}
)

Return shape (PNG):

{
  "status": "success",
  "content": [{"type":"image","data":"<base64>","mimeType":"image/png"}]
}

Configuration

The server can be configured via environment variables or command line arguments:

Server Settings

  • MCP_TRANSPORT - Transport type: streamable-http or stdio (default: streamable-http)

  • MCP_HOST - Host address (default: 0.0.0.0)

  • MCP_PORT - Port number (default: 8000)

  • LOG_LEVEL - Logging level: DEBUG, INFO, WARNING, ERROR, CRITICAL (default: INFO)

  • MCP_DEBUG - Enable debug mode: true or false (default: false)

Chart Settings

  • CHART_DEFAULT_WIDTH - Default chart width in pixels (default: 800)

  • CHART_DEFAULT_HEIGHT - Default chart height in pixels (default: 600)

  • CHART_DEFAULT_DPI - Default chart DPI (default: 100)

  • CHART_MAX_DATA_POINTS - Maximum data points per chart (default: 10000)

Command Line Usage

With uvx (recommended):

uvx --from git+https://github.com/mr901/mcp-plots.git mcp-plots --help

# Examples:
uvx --from git+https://github.com/mr901/mcp-plots.git mcp-plots --port 8080 --log-level DEBUG
uvx --from git+https://github.com/mr901/mcp-plots.git mcp-plots --chart-width 1200 --chart-height 800

Traditional Python:

python -m src --help

# Examples:
python -m src --transport streamable-http --host 0.0.0.0 --port 8000
python -m src --log-level DEBUG --chart-width 1200 --chart-height 800

Docker

Build image:

docker build -t mcp-plots .

Run container with custom configuration:

docker run --rm -p 8000:8000 \
  -e MCP_TRANSPORT=streamable-http \
  -e MCP_HOST=0.0.0.0 \
  -e MCP_PORT=8000 \
  -e LOG_LEVEL=INFO \
  -e CHART_DEFAULT_WIDTH=1000 \
  -e CHART_DEFAULT_HEIGHT=700 \
  -e CHART_DEFAULT_DPI=150 \
  -e CHART_MAX_DATA_POINTS=5000 \
  mcp-plots

Cursor MCP Integration

Quick Setup for Cursor

The Plots MCP Server is designed to work seamlessly with Cursor's MCP support. Here's how to integrate it:

1. Add to Cursor's MCP Configuration

Add this to your Cursor MCP configuration file (~/.cursor/mcp.json or similar):

{
  "mcpServers": {
    "plots": {
      "command": "uvx",
      "args": [
        "--from", 
        "git+https://github.com/mr901/mcp-plots.git@main",
        "mcp-plots",
        "--transport", 
        "stdio"
      ],
      "env": {
        "LOG_LEVEL": "INFO",
        "CHART_DEFAULT_WIDTH": "800",
        "CHART_DEFAULT_HEIGHT": "600"
      }
    }
  }
}

2. Alternative: HTTP Transport

For HTTP-based integration:

{
  "mcpServers": {
    "plots-http": {
      "command": "uvx",
      "args": [
        "--from", 
        "git+https://github.com/mr901/mcp-plots.git@main", 
        "mcp-plots",
        "--transport", 
        "streamable-http",
        "--host", 
        "127.0.0.1",
        "--port", 
        "8000"
      ]
    }
  }
}

3. Local Development Setup

For local development (if you have the code cloned):

{
  "mcpServers": {
    "plots-dev": {
      "command": "python",
      "args": ["-m", "src", "--transport", "stdio"],
      "cwd": "/path/to/mcp-plots",
      "env": {
        "LOG_LEVEL": "DEBUG"
      }
    }
  }
}

4. Verify Integration

After adding the configuration:

  1. Restart Cursor

  2. Check MCP connection in Cursor's MCP panel

  3. Test with a simple chart:

    Create a bar chart showing sales data: A=100, B=150, C=80

MERMAID-First Approach

This server prioritizes MERMAID output by default because:

  • Renders instantly in Cursor - No external viewers needed

  • Interactive - Cursor can analyze and discuss the diagrams

  • Lightweight - Fast generation and display

  • Scalable - Vector-based, works at any zoom level

Chart Types with Native MERMAID Support:

  • line, bar, pie, areaxychart-beta format

  • histogramxychart-beta with automatic binning

  • funnel → Styled flowchart with color gradients

  • gauge → Flowchart with color-coded value indicators

  • sankey → Flow diagrams with source/target styling

Available Tools

render_chart

Main chart generation tool with MERMAID-first approach.

Parameters:

  • chart_type - Chart type (line, bar, pie, scatter, heatmap, etc.)

  • data - List of data objects

  • field_map - Field mappings (x_field, y_field, category_field, etc.)

  • config_overrides - Chart configuration overrides

  • output_format - Output format (mermaid [default], mcp_image, mcp_text)

Special Modes:

  • chart_type="help" - Show available chart types and themes

  • chart_type="suggest" - Analyze data and suggest field mappings

configure_preferences

Interactive configuration tool for setting user preferences.

Parameters:

  • output_format - Default output format (mermaid, mcp_image, mcp_text)

  • theme - Default theme (default, dark, seaborn, minimal)

  • chart_width - Default chart width in pixels

  • chart_height - Default chart height in pixels

  • reset_to_defaults - Reset all preferences to system defaults

Features:

  • Persistent Settings - Saved to ~/.plots_mcp_config.json

  • Live Preview - Shows sample chart with current settings

  • Override Support - Use config_overrides for one-off changes

Documentation

Additional Resources

Chart Examples

Basic Bar Chart:

{
  "chart_type": "bar",
  "data": [
    {"category": "Sales", "value": 120},
    {"category": "Marketing", "value": 80},
    {"category": "Support", "value": 60}
  ],
  "field_map": {
    "category_field": "category", 
    "value_field": "value"
  }
}

Time Series Line Chart:

{
  "chart_type": "line",
  "data": [
    {"date": "2024-01", "revenue": 1000},
    {"date": "2024-02", "revenue": 1200},
    {"date": "2024-03", "revenue": 1100}
  ],
  "field_map": {
    "x_field": "date",
    "y_field": "revenue"
  }
}

Funnel Chart:

{
  "chart_type": "funnel",
  "data": [
    {"stage": "Awareness", "value": 1000},
    {"stage": "Interest", "value": 500}, 
    {"stage": "Purchase", "value": 100}
  ],
  "field_map": {
    "category_field": "stage",
    "value_field": "value"
  }
}

🔧 Configuration

Environment Variables

  • MCP_TRANSPORT - Transport type (streamable-http | stdio)

  • MCP_HOST - Host address (default: 0.0.0.0)

  • MCP_PORT - Port number (default: 8000)

  • LOG_LEVEL - Logging level (default: INFO)

  • MCP_DEBUG - Enable debug mode (true | false)

  • CHART_DEFAULT_WIDTH - Default chart width in pixels (default: 800)

  • CHART_DEFAULT_HEIGHT - Default chart height in pixels (default: 600)

  • CHART_DEFAULT_DPI - Default chart DPI (default: 100)

  • CHART_MAX_DATA_POINTS - Maximum data points per chart (default: 10000)

User Preferences

Personal preferences are stored in ~/.plots_mcp_config.json:

{
  "defaults": {
    "output_format": "mermaid",
    "theme": "default",
    "chart_width": 800,
    "chart_height": 600
  },
  "user_preferences": {
    "output_format": "mcp_image",
    "theme": "dark"
  }
}

🚀 Advanced Usage

Custom Themes

Available themes: default, dark, seaborn, minimal, whitegrid, darkgrid, ticks

High-Resolution Charts

uvx --from git+https://github.com/mr901/mcp-plots.git mcp-plots \
  --chart-width 1920 \
  --chart-height 1080 \
  --chart-dpi 300

Performance Optimization

  • Use max_data_points to limit large datasets

  • MERMAID output is fastest for quick visualization

  • PNG output for high-quality static images

  • SVG output for scalable vector graphics

🐛 Troubleshooting

Common Issues

Issue: Charts not rendering in Cursor

  • Solution: Ensure output_format="mermaid" (default)

  • Check: MCP server connection in Cursor

Issue: uvx command not found

  • Solution: Install uv: curl -LsSf https://astral.sh/uv/install.sh | sh

Issue: Port already in use

  • Solution: Use different port: --port 8001

Issue: Large datasets slow

  • Solution: Sample data or increase --max-data-points

Debug Mode

uvx --from git+https://github.com/mr901/mcp-plots.git mcp-plots \
  --debug \
  --log-level DEBUG

📝 Notes

  • Matplotlib runs headless (Agg backend) in the container

  • For large datasets, sample your data for responsiveness

  • Chart defaults can be overridden per-request via config_overrides

  • MERMAID charts render instantly in Cursor for the best user experience

  • User preferences persist across sessions and apply to all charts by default

Available Tools

2 tools
configure_preferencesA
    Interactive configuration tool for setting user preferences.
    
    Parameters:
    - output_format: "mermaid", "mcp_image", or "mcp_text"
    - theme: "default", "dark", "seaborn", "minimal", etc.
    - chart_width: Chart width in pixels
    - chart_height: Chart height in pixels  
    - reset_to_defaults: Reset all preferences to system defaults
    
    If no parameters provided, shows current configuration with sample.
    
ParametersJSON Schema
NameRequiredDescriptionDefault
output_formatNo
themeNo
chart_widthNo
chart_heightNo
reset_to_defaultsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/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. It discloses that the tool can both set preferences and show current configuration, which is useful behavioral context. However, it doesn't mention permission requirements, persistence mechanisms, or whether changes are immediate/reversible, leaving gaps for a configuration tool.

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 a clear purpose statement followed by a parameter list and behavioral note. It's appropriately sized at 6 lines, though the parameter explanations could be slightly more concise (e.g., combining width/height descriptions).

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 5 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameter semantics. The presence of an output schema means return values don't need explanation. The main gap is lack of sibling tool differentiation and some behavioral context like persistence 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?

The description adds significant value beyond the input schema, which has 0% description coverage. It provides specific semantics for all 5 parameters: enumerating valid values for 'output_format' and 'theme', explaining units for 'chart_width' and 'chart_height', and clarifying the boolean 'reset_to_defaults' parameter's effect.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 as 'Interactive configuration tool for setting user preferences' with specific parameters listed. It distinguishes from the sibling 'render_chart' by focusing on configuration rather than rendering, though the distinction could be more explicit.

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

Usage Guidelines3/5

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

The description provides implied usage guidance by stating 'If no parameters provided, shows current configuration with sample,' which suggests when to use it for read vs. write operations. However, it lacks explicit guidance on when to use this tool versus alternatives like 'render_chart' or other configuration methods.

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

render_chartA
    Render a chart from tabular data and return MCP-compatible content.
    
    Special modes:
    - chart_type="help": Returns available chart types, themes, and field suggestions
    - chart_type="suggest": Analyzes your data and suggests field mappings (requires data)

    Parameters:
    - chart_type: chart type ("line", "bar", "pie", etc.) or "help"/"suggest"
    - data: list of objects (rows) - optional for help mode
    - field_map: keys like x_field, y_field, category_field, value_field, group_field, size_field
    - config_overrides: subset of ChartConfig as dict (width, height, title, theme, dpi, etc.)
    - options: generator-specific options (e.g., smooth, stack)
    - output_format: MCP_IMAGE (PNG), MCP_TEXT (SVG), or MERMAID
    
ParametersJSON Schema
NameRequiredDescriptionDefault
chart_typeYes
dataNo
field_mapNo
config_overridesNo
optionsNo
output_formatNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/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 describes key behaviors like special modes ('help' and 'suggest'), return types (MCP-compatible content), and optional parameters, but lacks details on error handling, performance limits, or authentication needs. This provides moderate transparency but leaves gaps for a tool with 6 parameters.

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 for general purpose, special modes, and parameters, making it easy to scan. It is appropriately sized with no redundant sentences, though it could be slightly more front-loaded by emphasizing the primary use case before special modes.

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 (6 parameters, nested objects) and the presence of an output schema (which reduces the need to explain return values), the description is mostly complete. It covers key usage scenarios and parameter semantics but lacks details on behavioral aspects like error conditions or rate limits, which are important for a rendering 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 schema description coverage is 0%, so the description must compensate. It adds significant meaning by explaining each parameter's purpose, such as 'chart_type' options ('line', 'bar', 'pie', etc.), 'data' as 'list of objects (rows)', and 'field_map' keys. However, it does not fully detail all aspects like the structure of 'config_overrides' or 'options', preventing a perfect 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 with specific verbs ('Render a chart from tabular data') and distinguishes it from the only sibling tool 'configure_preferences' by focusing on chart generation rather than configuration. It also mentions the return type ('MCP-compatible content'), making the purpose explicit and differentiated.

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 usage contexts by detailing special modes ('help' and 'suggest') and when data is required (e.g., 'requires data' for 'suggest' mode). However, it does not explicitly state when to use this tool versus the sibling 'configure_preferences' or other alternatives, which limits the score to 4.

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.

  1. 2 tool updatesv1.0.0
    • Changedconfigure_preferences1 field changed
      • addedInput schema / title
        Added value: +"configure_preferencesArguments"
    • Changedrender_chart1 field changed
      • addedInput schema / title
        Added value: +"render_chartArguments"
  2. 2 tool updates
    • First observedconfigure_preferences
    • First observedrender_chart

TDQS

A3.7/5.0
Disambiguation5/5

The two tools have completely distinct purposes with no overlap: configure_preferences handles user settings and defaults, while render_chart focuses on data visualization and chart generation. An agent would never confuse these tools as they address separate concerns in the plotting workflow.

Naming Consistency4/5

Both tools follow a consistent verb_noun pattern (configure_preferences, render_chart) with clear action-object naming. The minor deviation is that 'configure' and 'render' are different verb types, but the pattern remains readable and predictable throughout the set.

Tool Count2/5

With only 2 tools for a plotting server, the surface feels severely under-scoped. While the tools cover configuration and rendering, there are obvious gaps in data manipulation, chart editing, export options, and batch operations that would be expected in a complete plotting toolkit.

Completeness2/5

The toolset is significantly incomplete for a plotting domain. Missing are essential operations like data transformation/cleaning, chart modification/updating, saving/exporting beyond immediate rendering, template management, and batch processing. Agents will hit dead ends when trying to perform common plotting workflows beyond basic render-and-configure.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • F
    license
    A
    quality
    D
    maintenance
    An MCP server that enables LLMs to generate high-quality SVG charts using matplotlib, supporting various plot types like line, bar, and heatmaps. It provides flexible configuration for dimensions and axis scales, returning either raw SVG content or paths to saved image files.
    9
    -
  • A
    license
    A
    quality
    D
    maintenance
    An MCP server that enables AI assistants to create, update, and publish Datawrapper charts through natural language. It provides tools for data synchronization, visual configuration, and retrieving chart images or editor links.
    8
    MIT

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/MR901/mcp-plots'

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