Skip to main content
Glama

Turn your Excel, CSV and SQL data into dashboards with Claude Code.

Ask a question. Showboard runs read-only queries and draws the charts. See the SQL behind every chart, and ask a follow-up to explore further.

Explore the demo  ·  Get started  ·  Documentation

English  ·  简体中文

“Show me my best seller of 2026, and how it compares with last year.”

2.7× cheaper  ·  3.5× fewer output tokens  ·  3.2× faster Claude Code with Showboard against Claude Code on its own, on the same questions and the same files. See the benchmark

One question becomes a dashboard of headline numbers, charts and tables, in your browser, beside your terminal or inside your app.

MCP server License: MIT Node.js 22.13 or later Listed on mcpservers.org Showboard MCP server – quality and maintenance score on Glama

Open source · MIT licensed · Runs on your computer · Also works with Codex, Cursor and other MCP-compatible agents

Star Showboard to follow updates.

Your agent can write charts. Why add Showboard?

Without Showboard, a chart request can become a coding task: read files, calculate results, write a page and wire up charts. Showboard gives your agent a ready-made way to query the data and display the answer.

Related MCP server: mcp-server-motherduck

Quick start

You need Node.js 22.13+ and a coding agent. Start with a folder of Excel or CSV files, a SQLite database, or a Postgres connection.

1. In Claude Code, install the plugin:

/plugin install showboard --marketplace rohanbeingsocial/showboard

Choose your data folder or database when prompted. Plugin instructions.

2. Ask about your data:

Which products brought in the most revenue, and how did that change month by month?

3. See the board in a pane beside the chat (type /board to open it) and at http://localhost:4711.

In your project, paste this into your agent:

Set up Showboard in this project: run npx showboard guide and follow it.

The guide walks your agent through setup and checks the connection with showboard doctor. Boards open at http://localhost:4710, or run npx showboard pane in a terminal beside your agent.

For a folder of spreadsheets:

cd my-reports
npx showboard init .

For a database:

npx showboard init --db ./shop.sqlite

Restart your agent in that folder and open http://localhost:4710. Claude Code is the default; add --agent codex,cursor,gemini to configure other agents.

For Postgres credentials, use the SHOWBOARD_DB environment variable instead of putting a password in settings files. See the setup guide.

For the Claude desktop app, download the .mcpb extension from the latest release. Install it through Settings → Extensions → Advanced settings → Install Extension. This path does not require a separate Node.js installation. Desktop instructions.

Just looking? Explore the browser demo before installing.

Start with the data you already have

Your data

What you can ask

A folder of Excel and CSV reports

“Which regions are behind target?” Join orders in a workbook with targets in a CSV.

A SQLite or Postgres database

“Show monthly revenue and the top five products.” Query your tables read-only.

Your own Node + React app

Put boards inside your app and expose the data sources and actions your agent can use. Integration guide · API reference

Spreadsheet loading handles title rows, blank rows, total rows, currency strings and common date formats. Each sheet becomes a queryable table; files reload when you save them.

Orders in Excel. Targets in CSV. One question shows the regional gaps and the queries behind them.

In a real app

It works on real data too. Meridian, a private investing app, has Showboard inside. Here Claude Code is asked whether silver rose each time the gold/silver ratio crossed above 90. It reads two years of MCX gold and silver prices from the app's own API and draws one board.

The ratio and silver side by side, each stretch above 90 marked in orange, and silver's moves 1, 3 and 6 months after each cross.

How it works

Benchmark

Across 24 answers each way in our Claude Code test, API-priced cost was $1.78 with Showboard vs $4.77 without, and elapsed time was 7.5 vs 24.3 minutes.

This was two runs on one dataset. Other agents have not been benchmarked, and Claude's hand-built pages were more individually designed. These results are evidence for this workload, not a guarantee for yours.

How it compares

Works with your agent

Showboard is an MCP server. It uses the coding agent and model access you already have.

showboard init --agent can configure Claude Code, Codex, Cursor, Gemini CLI, OpenCode, VS Code, Windsurf, Antigravity and BharatCode.

Claude Code is tested end to end. Setup support for other agents does not mean they have all received the same testing. Agent configuration and testing status.

A few things to know

If something doesn't work

More fixes are in the setup guide. If yours isn't there, open an issue with what npx showboard doctor prints.

Considering using Showboard?

The documentation covers the details needed to decide whether it fits your workflow:

Help shape Showboard

Showboard is young, MIT licensed and built with AI assistance, mostly Claude Code. It has a test suite and a reproducible benchmark; real-world feedback is welcome.

Report a problem · Contribute · Read the docs · What's new · MIT license

Star Showboard to follow updates.

Available Tools

8 tools
describe_dataA

List what you can read: the database tables and columns query_data can use (with estimated row counts), and the app's named data sources for use_source. Call it before writing SQL against tables you have not seen.

Inputs: no named parameters.

drawA

Draw a board on the user's screen in one call. items, in reading order:

  • a part: sql (one read-only SELECT), dataset or source, with an optional title. The chart is picked from its rows: dates with numbers → line, labels with numbers → bars, one row → headline numbers, else a table; rows like (date, name, value) get a line per name. Choose yourself with show, x, y, series and formats, or draw it with any component and props (its dataset is filled in).

  • {note, title?, tone?}: your text. Quote only figures you have read.

  • {row: [parts]} side by side; {section, subtitle?, items} a titled group. The database computes every number: aggregate, rebase and round in SQL. Put values the user may change in params (:name in the SQL) and add save_as to keep the board as a recipe, so the same board for other values is one recipe call. Returns the rows of each part (the first and last of long ones) to check. Components: Grid {columns?}: Places its children side by side in equal columns, wrapping to new rows. Section {title, subtitle?}: A titled group of children, stacked. Metric {label, dataset, field, row?, format?, caption?}: One headline number read from a dataset cell (row 0 unless row is set). LineChart {dataset, x, y, title?, format?}: Lines over x (dates or ordered labels), one line per y column. BarChart {dataset, x, y, title?, format?, horizontal?}: Bars per x category, one bar per y column. horizontal suits long labels. PieChart {dataset, label, value, title?, format?}: Donut of value by label; beyond 7 slices the rest are grouped as Other. Table {dataset, columns?, limit?, title?}: Rows of a dataset. columns picks and orders them (all when omitted): column names, or { field, label?, format? }. Note {text, title?, tone?}: Your explanation in plain text. Lines starting with '- ' become bullets; bold works. tone colours it. ActionButton {label, action, input?}: A button that runs one of the app's actions (see get_screen) with the given input. The app can add its own components; get_screen lists them.

Inputs: items (required), title (required), id, params, +2 more.

get_screenA

What the user's browser shows now: the page and app state the app publishes, the actions you can run with ui_act (with their inputs), any components the app adds for boards, and the board on screen. Call it before ui_act, and to see what the user is looking at.

Inputs: no named parameters.

list_boardsA

List saved boards, newest first. show_board with an id reopens one.

Inputs: limit.

query_dataA

Run one read-only SQL SELECT against the app's SQLite database and keep the rows as a dataset named name that boards can draw. The database computes every number: aggregate, sort and round in SQL, not in your head. Returns the columns, the row count and the first rows. At most 5000 rows per query. Reusing a name replaces that dataset.

Inputs: sql (required), name (required), preview_rows.

recipeA

Draw a ready-made board in one call: name a recipe and its values (lists as arrays). Use one whenever it fits the question; draw makes new kinds of boards. note puts your text at the top (quote only figures you have read); title replaces the recipe's. No recipes yet: draw with save_as adds one.

Inputs: name (required), id, note, title, +1 more.

show_boardA

The long form of draw: a json-render spec you wire yourself, for what draw cannot say. Pass only id to reopen a saved board. { "root": "", "elements": { "": { "type": "", "props": {…}, "children": ["", …] } } }, with the components listed under draw. Every number comes from a dataset (query_data or use_source): components take a dataset name and column names, and any other prop can read a cell with { "$state": "/data///" }. Do not type figures into props. In a Note, only quote figures you read from a dataset. Pass id (from an earlier board) to change that board in place.

Inputs: id, spec, title.

ui_actB

Run one of the app's actions in the user's browser: open a page, set a filter, select something. get_screen lists the actions and their inputs. Returns what the action returned.

Inputs: action (required), input.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.7/5.0

    Scored across 8 tools

    Disambiguation4/5

    Most tools map to a distinct action (introspect, query, list, inspect, act), but three tools — recipe, draw, show_board — all produce boards and their boundaries rest on soft guidance like 'the long form of draw' and 'use a recipe whenever it fits.' The descriptions mitigate the overlap well, but an agent still has to judge which board-authoring path applies.

    Naming Consistency3/5

    The majority follow a verb_noun or verb-object pattern (describe_data, list_boards, query_data, show_board, get_screen, ui_act, though ui_act inverts to noun_verb). The bare names 'recipe' (a noun) and 'draw' (a bare verb) break the pattern and make the set feel mixed.

    Tool Count5/5

    Eight tools is well within the sweet spot, and each one earns its place: data introspection, query, three tiers of board rendering, board listing, screen inspection, and browser action. Nothing feels redundant at the count level.

    Completeness4/5

    The core lifecycle is covered: describe data, query it, render a board (simple or full spec), save/list boards, and inspect/drive the app. Gaps are minor: there is no delete or rename for boards, no way to enumerate saved recipes or manage stored datasets, which agents can work around by reusing names.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers