Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@data-report-mcp analyze sales.csv and return an Excel report with charts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local-first Model Context Protocol (MCP) server that turns a CSV/XLSX table into a real data analysis report — summary statistics, duplicate / missing diagnostics, top category frequencies, pairwise correlations, a Chinese Markdown insights writeup, and an Excel workbook with native interactive charts.
🔒 100% local, no API key, no network. Business / financial spreadsheets
never leave the machine. There is no telemetry upload — only an optional
local usage counter under ~/.cache/data-report-mcp.
🧮 No pandas. Runs on the standard library + openpyxl, so it bundles
small and starts fast inside an MCP host.
🔌 Two transports: stdio (Claude Desktop / Cursor / any MCP client) and streamable-http for a hosted endpoint.
🆓 Anonymous free tier (100 tables / 30 days per client); over-quota returns
an in-band QUOTA_EXCEEDED signal, it never silently bills.
Tool | Purpose |
| Analyze a |
| Service status + free-tier limits. |
analyze_table accepts the raw file as base64 (preferred) or a direct
https URL to a .csv/.xlsx. Inputs larger than 30 MB are rejected.
Related MCP server: MCP Tabular Data Analysis Server
pip install -e . # or: pip install data-report-mcp
# stdio (default MCP transport)
python -m data_report_mcp.server
# streamable-http
REMOTE_TRANSPORT=http MCP_PORT=5070 python -m data_report_mcp.server{
"mcpServers": {
"data-report": {
"command": "python",
"args": ["-m", "data_report_mcp.server"]
}
}
}Var | Default | Meaning |
|
| anonymous monthly table limit |
| (unset) | paid key that bypasses the quota |
|
| local usage-counter directory |
|
| http transport options |
Overall: row/column count, duplicate rows, columns with missing rate ≥ 20%.
Numeric columns: min / max / mean / median / sum / stdev / missing rate.
Categorical columns: unique count + top-5 value frequencies.
Significant pairwise correlations (Pearson |r| ≥ 0.5).
An Excel workbook (return_xlsx=true) with sheets 概览 / 数值统计 / 明细 /
分布_* (each with a native bar chart) / 显著相关.
Output is a starting point for analysis, not a conclusion: correlation is not causation — combine it with business judgment.
MIT. Core analysis adapted from the open data-report local toolkit.
Analyze a CSV/XLSX table fully locally: infer numeric/categorical columns, compute shape, missing rate, duplicates, min/max/mean/median/sum/ stddev, top frequencies for text columns and pairwise correlations (|r|>=0.5), and return a Chinese Markdown insights report. Optionally a base64 Excel workbook with native interactive bar charts.
Args: file_base64: raw CSV/XLSX content as base64 (preferred). file_url: direct HTTPS URL to a .csv/.xlsx (alternative). filename: original filename (used only to decide csv vs xlsx). charts: max category columns to chart in the xlsx workbook. return_xlsx: when true, include the generated workbook as base64. api_key: paid key to bypass the anonymous monthly quota.
| Name | Required | Description | Default |
|---|---|---|---|
| charts | No | ||
| api_key | No | ||
| file_url | No | ||
| filename | No | upload.csv | |
| file_base64 | No | ||
| return_xlsx | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it discloses meaningful behavior: processing happens locally, the report is Chinese Markdown, the xlsx includes native interactive bar charts, and there is an anonymous monthly quota with a paid-key bypass. Gaps remain around size limits for base64 payloads, failure/error behavior for malformed files, and whether output is truncated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the capability and output before the argument list, and the Args block is scannable with aligned labels. The opening sentence is dense with metric enumerations that could be trimmed, but every element is informative rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must supply both behavior and returns — and it largely does: it names the output format (Chinese Markdown insights), the optional xlsx artifact, the metrics computed, and the quota/auth model. Only edge-case handling (bad input, size limits, quota-exceeded responses) is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the Args block documents all six parameters with semantics beyond the names — file_base64 as raw content, file_url as a direct HTTPS link, filename used 'only to decide csv vs xlsx', charts as max category columns to chart, return_xlsx as an opt-in base64 workbook, and api_key as a quota bypass. This fully compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource (analyze a CSV/XLSX table) with explicit scope: 'fully locally', and an enumerated set of computed metrics (shape, missing rate, duplicates, min/max/mean/median/sum/stddev, correlations, top frequencies). The `health` sibling offers no overlap, so no differentiation is needed. An agent knows exactly what this returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete selection guidance between the two input paths ('file_base64: preferred' vs 'file_url: alternative') and explains the quota model with the bypass (api_key for the anonymous monthly quota). It does not state when NOT to use this tool or alternative tools for the same job, but the input-path precedence and quota note are genuine, actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Service health + free-tier limits. No auth required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add one genuinely useful behavioral fact — no authentication is needed — and implies a read-only diagnostic that reports free-tier limits. It says nothing about rate limits, caching, latency, or what a degraded result looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, no filler, and the primary purpose (service health) is front-loaded ahead of the scope detail. Nothing could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotation tool with no output schema, the definition covers what is needed to decide to call it: it is a health probe with free-tier limit data and no auth. It does not describe the shape of the returned status, which is a minor gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty, so there are no parameter semantics to document. A baseline of 4 is appropriate; this dimension is effectively non-applicable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource and scope: service health status plus free-tier limit information. It is immediately distinguishable from the only sibling, extract_pdf, which is unrelated. It stops short of a 5 only because it is telegraphic rather than a full verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'No auth required' hints at the calling context and removes a prerequisite, but the description never says when to invoke this versus anything else, nor what state or errors it signals. Usage is implied by the name and the health-check convention rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_tablehealthScored across 2 tools
health and analyze_table have completely distinct purposes: one checks service status and quota, the other performs local table analysis. There is no overlap or ambiguity in choosing between them.
Both names use snake_case consistently. However, 'health' is a bare noun while 'analyze_table' follows a verb_noun pattern, creating a minor structural inconsistency.
With only 2 tools, and one being a trivial health check, the functional surface is thin for a server named data-report-mcp. The single analyze_table tool is comprehensive, but the overall set feels under-scoped.
The core single-table analysis and reporting workflow is well covered, including stats, correlations, and optional charts. However, notable gaps exist: no support for multi-table comparison, time-series analysis, data cleaning, or saved report retrieval, limiting real-world reporting use cases.
Upload spreadsheets, get plain-English analysis with real computed charts and quality scores.
Convert and clean tables: CSV, JSON, dedupe, stats. Free.
A statistical analyst in your AI chat: bring data and a question, get a citable, re-runnable report.
Ask questions about a CSV in plain English and get answers, charts and cleaned data back.