Skip to main content
Glama
Ridadata

mcp-data-profiler

by Ridadata

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.

CI Python PyPI License: MIT MCP Registry


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:

A terminal running python demo.py: a 237 KB, 5,000-row CSV is reduced to a 2 KB profile in a
tenth of a second, with six data-quality findings listed across four columns

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:

An MCP client is asked what is in orders.csv: it calls profile_dataset, gets a 2.3 KB profile
back, and reports every column with its type, range and quality flags

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 .gz variants of the text formats.

  • Path confinement — optional --root restricts 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"| A

All 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-profiler
pip install git+https://github.com/Ridadata/mcp-data-profiler.git

Claude Code

claude mcp add data-profiler -- mcp-data-profiler

Claude 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

path

str

required

File to profile; .gz is decompressed transparently

sample_rows

int | null

50000

Rows to read. null reads everything — exact, slower

max_columns

int

100

Cap on columns described, so wide tables stay small

top_k

int

5

Frequent values listed per categorical column

sheet

str | null

first sheet

Which Excel sheet to profile, by name

Quality flags

Flag

Meaning

all_null

Column is entirely empty

constant

Only ever one value — no signal

high_cardinality_possible_id

Nearly all values distinct; an identifier, not a feature

numeric_stored_as_text

Numbers typed as strings; comparisons and sorting will be wrong

date_stored_as_text

Dates typed as strings; same problem

mixed_types

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"]) # 0

Example 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 sheet to 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 files

CI 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 tool
profile_datasetA
Read-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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
sheetNo
top_kNo
max_columnsNo
sample_rowsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev0.1.1
    • First observedprofile_dataset

TDQS

A4.3/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count2/5

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.

Completeness2/5

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

ActivityMaintained
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

  • A
    license
    A
    quality
    Not graded
    maintenance
    An 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
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    An 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.
    -
  • F
    license
    A
    quality
    A
    maintenance
    MCP 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.
    39
    81
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Zero-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

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