mcp-data-profiler
This server profiles local data files to generate a compact, structured summary of schema, statistics, and data quality without reading raw rows.
Key capabilities:
Profile diverse formats: CSV, TSV, Parquet, JSON/JSONL/NDJSON, Excel (XLSX/XLSM/XLS), and gzip-compressed variants.
Per-column statistics: data type, null count and %, distinct count, sample values, numeric quartiles, date ranges, and top frequent values for categorical columns.
Data-quality flags: detects all-null, constant, probable ID, mixed types, numbers/dates stored as text.
Control profiling: limit sample rows, max columns, top frequent values, and select Excel sheets.
Overall dataset info: file details, shape (rows profiled vs total), column count, duplicate row count, and sampling status indication.
Large file handling: samples 50k rows by default for speed; can fully read by setting
sample_rows=null.Security: optional directory confinement via
--root.Python library: importable directly via
from mcp_data_profiler import profile_dataset.
Click on "Install 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., "@mcp-data-profilerwhat's in data/orders.csv?"
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.
mcp-data-profiler
Let an AI agent understand a dataset without reading it.
An MCP server that turns a CSV, Parquet, JSON, or Excel file into a compact structured profile — types, ranges, missing values, and likely data-quality problems — instead of raw rows.
Overview
To let an AI agent reason about a data file, you normally paste rows into the conversation. That is expensive, truncates on anything large, and still leaves the model guessing at column types and null rates.
This server answers the question directly. One tool call returns a structured summary that is orders of magnitude smaller than the data and says more about it:
Dataset | Raw file | Profile | Reduction | Time |
Google Play Store (2.3M rows × 24 cols) | 645 MB | 13 KB | 49,205× | 1.9 s |
SNCF punctuality (10,687 rows × 26 cols) | 2 MB | 13 KB | 189× | 0.2 s |
Orders sample (5,000 rows × 6 cols) | 241 KB | 2.3 KB | 104× | 0.1 s |
The 645 MB file cannot go into a context window at any price. It is fully characterised here in under two seconds.
Related MCP server: MCP File Analyzer
Demo
python demo.py generates a deliberately messy dataset, profiles it, and reports what came back:

The same profiler seen from an MCP client — one question, one profile_dataset call, and the file
is characterised without a single row entering the conversation:

Three real problems surfaced before any analysis began: a column that never varies, one that is
entirely empty, and a date column that sorts as text — so "2024-10-01" < "2024-9-01" — silently
corrupting any time-based result.
Features
Six data-quality flags — constant, all-null, probable ID, mixed types, and numbers or dates stored as text.
Full column statistics — dtype, null count and percentage, distinct count, sample values, quartiles for numerics, ranges for dates, frequent values for categories.
Bounded output — the response stays small no matter how wide the input, and always reports what it truncated.
Honest sampling — large files are sampled, but never silently; the true row count is always included.
Five formats, eleven extensions —
.csv.tsv.txt.parquet.pq.json.jsonl.ndjson.xlsx.xlsm.xls, plus.gzvariants of the text formats.Path confinement — optional
--rootrestricts profiling to a single directory.Zero configuration — no database, no index, no warm-up. Point it at a file.
Architecture
flowchart LR
A["MCP client<br/>Claude Code, Claude Desktop"]
B["server.py<br/>MCP adapter"]
C["profiler.py<br/>pure pandas, no MCP"]
D[("Local files<br/>CSV, Parquet<br/>JSON, Excel")]
A -->|"profile_dataset(path)"| B
B -->|"validate, confine to --root"| C
C -->|"sampled read"| D
D -->|"DataFrame"| C
C -->|"bounded JSON profile"| B
B -->|"tool result"| AAll profiling logic lives in profiler.py, which imports nothing from MCP. It is unit-testable
without a protocol harness and usable as an ordinary Python library. server.py is only the
adapter.
Installation
Requires Python 3.10+.
pip install mcp-data-profilerpip install git+https://github.com/Ridadata/mcp-data-profiler.gitClaude Code
claude mcp add data-profiler -- mcp-data-profilerClaude Desktop and other MCP clients
Add to your client's MCP configuration:
{
"mcpServers": {
"data-profiler": {
"command": "mcp-data-profiler"
}
}
}To confine the server to one directory, add "args": ["--root", "/path/to/your/data"].
Usage
Once registered, ask in plain language:
"Profile
data/orders.csv""Which columns have missing values?"
"Is this dataset clean enough to model?"
Tool reference
profile_dataset(path, sample_rows=50000, max_columns=100, top_k=5, sheet=None)
Argument | Type | Default | Description |
|
| required | File to profile; |
|
|
| Rows to read. |
|
|
| Cap on columns described, so wide tables stay small |
|
|
| Frequent values listed per categorical column |
|
| first sheet | Which Excel sheet to profile, by name |
Quality flags
Flag | Meaning |
| Column is entirely empty |
| Only ever one value — no signal |
| Nearly all values distinct; an identifier, not a feature |
| Numbers typed as strings; comparisons and sorting will be wrong |
| Dates typed as strings; same problem |
| One column holding several unrelated Python types |
As a Python library
from mcp_data_profiler import profile_dataset
profile = profile_dataset("data/orders.csv", sample_rows=None)
print(profile["shape"]) # {'rows_profiled': 5000, 'total_rows': 5000, 'columns': 6}
print(profile["duplicate_rows"]) # 0Example output
Verbatim output for the sample dataset produced by python demo.py, with three of the six
columns shown:
{
"file": { "name": "orders.csv", "format": "csv", "size_bytes": 247263 },
"shape": { "rows_profiled": 5000, "total_rows": 5000, "columns": 6 },
"sampled": false,
"columns": [
{
"name": "order_id",
"dtype": "str",
"null_count": 0,
"null_pct": 0.0,
"unique_count": 5000,
"sample_values": ["ORD-000000", "ORD-000001", "ORD-000002"],
"flags": ["high_cardinality_possible_id"]
},
{
"name": "amount_eur",
"dtype": "float64",
"null_count": 0,
"null_pct": 0.0,
"unique_count": 1368,
"stats": {
"min": 2.65, "max": 1369.65, "mean": 684.2364, "std": 395.254451,
"q25": 341.65, "median": 683.65, "q75": 1025.65
},
"sample_values": [2.65, 39.65, 76.65]
},
{
"name": "currency",
"dtype": "str",
"null_count": 0,
"null_pct": 0.0,
"unique_count": 1,
"top_values": [{ "value": "EUR", "count": 5000 }],
"sample_values": ["EUR", "EUR", "EUR"],
"flags": ["constant"]
}
],
"duplicate_rows": 0
}Note that order_id carries no top_values: for a near-unique column every count would be 1,
so the list is omitted rather than padding the response with noise.
When a file is sampled, the profile also carries "sampled": true, the true total_rows, and a
sampling_note saying so.
Design notes
Bounded output. The tool must cost less than the data it describes, so the response is capped
regardless of input width and long strings are truncated. Near-unique columns skip the
frequent-values list, since every count would be 1.
Honest sampling. Large files are profiled from a sample, but the result always carries
"sampled": true alongside the true row count — a silently sampled statistic is a wrong
statistic. Row counts come from Parquet metadata or a raw newline scan, never a full parse into
memory.
No silent wrong answers. The same rule governs every default that could mislead. A workbook's first sheet is often a title page, so Excel profiles always name the sheet used and list the others rather than reporting an untouched sheet as a clean dataset. CSV delimiters are inferred by testing candidates for a stable column count, which handles the semicolon files common in European open data without the header-mangling that character-frequency sniffers cause. Compressed files are decompressed before either check, since inspecting gzip bytes as text yields a plausible-looking answer that is entirely wrong.
Path safety. --root confines profiling to one directory. Paths are canonicalised before the
check, so .. and symlinks cannot escape it.
Limitations
Read-only, local files. No databases, no URLs, no writes.
Sampled by default. Statistics reflect the first 50,000 rows unless you pass
sample_rows=null.Row-oriented. No cross-column correlations, outlier detection, or plots.
pandas parsing rules apply. The profile shows what pandas sees, which is what your own code will see. Notably
"NA","N/A", and"None"are read as missing, so a region column containing"NA"for North America will report nulls. That trap is surfaced, not hidden.Nested JSON is not flattened. Unhashable cells make the duplicate check inapplicable, and it is reported as
null.One Excel sheet per call. The profile names the sheet read and lists the rest; pass
sheetto switch.
Development
git clone https://github.com/Ridadata/mcp-data-profiler.git
cd mcp-data-profiler
pip install -e ".[dev]"
pytest # 40 tests
ruff check src tests demo.py # lint
ruff format --check src tests demo.py # formatting
python demo.py # profile a generated sample dataset
python demo.py path/to/your.csv # profile your own filesCI runs the suite on Python 3.10–3.13 (Linux) plus Windows and macOS, and performs a real stdio handshake against the built server to confirm it starts and advertises its tool.
Releasing
Publishing to PyPI is automated via Trusted Publishing, so no API token is stored in this
repository. Publishing a GitHub Release triggers .github/workflows/release.yml, which builds the
distributions, verifies the built wheel actually installs and imports, and uploads it.
Issues and pull requests are welcome.
Roadmap
Publish to PyPI
Gzip-compressed inputs (
.csv.gz,.jsonl.gz)List on the official MCP registry
Cross-column correlation summary for numeric features
Multi-sheet Excel profiling in a single call
Remote sources (
s3://,https://)
License
MIT © Rida Aderkane
Available Tools
1 toolprofile_datasetARead-only
Summarise the structure and quality of a local data file.
Call this whenever you need to understand a dataset — its columns, types, ranges, missing values, or quality problems — before analysing it, writing code against it, or answering questions about it. Prefer this over reading the file directly: it returns a compact summary instead of raw rows, so it works on files far too large to read, at a small fraction of the tokens.
Reports per column: dtype, null count and percentage, distinct count, sample values, quartiles for numbers, date ranges, and the most frequent values for categories. Flags likely problems: all-null and constant columns, probable ID columns, mixed types, and numbers or dates that were stored as text.
Args: path: Path to the file. Supports .csv, .tsv, .parquet, .json, .jsonl, .xlsx, and .xls. sample_rows: Profile at most this many rows. Pass null to read every row, which is slower on large files but makes all statistics exact. The result always states whether it was sampled. max_columns: Describe at most this many columns, so the response stays small on very wide tables. The true column count is always reported. top_k: How many of the most frequent values to list per categorical column. sheet: For Excel workbooks, the name of the sheet to profile. Defaults to the first sheet, which is often a title or notes page rather than the data. The result lists every available sheet, so if the one profiled looks empty or wrong, call again naming another.
Returns: A profile with file info, shape, per-column detail, and duplicate row count.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| sheet | No | ||
| top_k | No | ||
| max_columns | No | ||
| sample_rows | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint=true annotation already covers the safety profile, and the description builds on it rather than repeating it. The description adds genuine behavioral context: it flags data-quality problems (all-null, constant, probable IDs, mixed types, text-stored numbers/dates), discloses sampling behavior ('The result always states whether it was sampled'), and explains the Excel sheet behavior (lists all sheets, warns the first may be a title page). This exceeds what annotations provide.
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?
The description is coherently structured with a purpose statement, a when-to-use paragraph, a reporting summary, and a clearly labeled Args block. It's dense but not bloated. It loses a point for length — the report-per-column enumeration plus the Args block are thorough but arguably verbose; still, nearly every sentence adds value, so it's firmly above average.
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 an output schema present, the description needn't detail return values, but it still gives a high-level Returns summary (file info, shape, per-column detail, duplicate rows). The tool is genuinely complex (5 params, multiple file formats, quality flags, Excel multi-sheet logic) and the description covers all of it comprehensively. This is effectively a complete specification for a complex tool.
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 documentation coverage is 0%, so the description carries the full burden, and it excels. Every one of the 5 parameters gets a substantive explanation beyond its schema type: path lists supported extensions; sample_rows explains that null reads every row (slower but exact), with the sampling caveat; max_columns explains the response-stays-small tradeoff and that true count is always reported; top_k quantifies behavior; sheet explains the default, the pitfall (title/notes page), and the recovery workflow (call again). This is exemplary parameter documentation.
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 opens with a specific verb+resource: 'Summarise the structure and quality of a local data file.' It immediately clarifies scope (local file, not remote) and enumerates exactly what it reports (columns, types, ranges, missing values, quality problems). Though no siblings exist to distinguish from, the description still clearly defines the tool's identity and full responsibility.
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?
The description gives explicit when-to-use guidance: 'Call this whenever you need to understand a dataset... before analysing it, writing code against it, or answering questions about it.' It also actively advises against an alternative approach: 'Prefer this over reading the file directly... works on files far too large to read, at a small fraction of the tokens.' This is model-level usage guidance that directly shapes agent behavior.
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 tool update
v0.1.1- First observed
profile_dataset
TDQS
Only one tool exists, so there is no possibility of ambiguity or misselection. The single tool's purpose is clearly stated with no overlap concerns.
With only one tool, the naming convention question is largely moot, but 'profile_dataset' follows a sensible verb_noun pattern that would be consistent if the set were expanded.
A single tool for a data profiling server is thin. While profiling is the core function, one would reasonably expect companion tools such as list_columns, detect_data_types, or list_sheets, making the surface feel under-scoped for the stated domain.
The server offers a single action for profiling but no way to list supported operations, compare datasets, export profiles, or inspect specific columns independently. Agents relying on this server can only get one broad summary with no ability to drill down or act on the results.
Maintenance
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
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Related MCP Servers
- AlicenseAqualityNot gradedmaintenanceAn MCP server that enables AI assistants to load, query, and analyze local CSV files using tools for filtering, aggregation, and grouping. It provides capabilities to describe schemas, calculate statistics, and sample data directly from CSV files.6-
- FlicenseNot gradedqualityDmaintenanceAn MCP server that enables the analysis of CSV and Parquet files by providing tools for statistical summaries, data previews, and structure exploration. It allows users to query local datasets and create sample data using natural language.-
- FlicenseAqualityAmaintenanceMCP server for tabular data retrieval that indexes local CSV, Excel, Parquet, and JSONL files once and answers questions via column profiles, filtered rows, server-side aggregations, and joins, drastically reducing token usage for large datasets.3981-
- AlicenseNot gradedqualityCmaintenanceZero-dependency MCP server and CLI for token-efficient inspection of local CSV/JSON/JSONL files, providing schema, samples, and paginated filtered queries to AI agents.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Ridadata/mcp-data-profiler'
If you have feedback or need assistance with the MCP directory API, please join our Discord server