What can you do with this server?

This server provides data profiling and quality analysis tools for tabular files (CSV, TSV, Parquet, Excel, JSON/JSONL), returning structured JSON for easy consumption by LLMs. * profile_dataset — One-call overview of a file: shape, memory usage, missing values, duplicate rows, per-column summaries (dtype, nulls, unique values, basic stats), and plain-language quality flags. * preview_data — View actual rows (head, tail, or random sample) up to 100 rows, to inspect real values, formatting, and encodings. * column_stats — Deep statistical dive into a single column: full percentiles, skew/kurtosis, outlier detection (IQR), histograms for numeric data, or top values and string-length stats for text/categorical columns. * detect_quality_issues — Data-quality audit grouped by severity (high/warning/info): duplicate rows, missing/constant/likely-ID columns, numbers stored as text, mixed types, whitespace padding, and empty strings. * suggest_dtypes — Recommendations for more memory-efficient or correct column types (e.g., text-to-numeric, low-cardinality-to-category, integer/float downcasting) with estimated memory savings. * compare_datasets — Diff two files side by side: row-count delta, added/removed columns, dtype changes, and per-column null-rate and mean comparisons.

How do I use data-profiler-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@data-profiler-mcp Profile sales_2025.csv and tell me what's in it." 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.

data-profiler-mcp

by haiiibin

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

data-profiler-mcp

PyPI PyPI Downloads Python Glama MCP Registry Listed in awesome-mcp-servers License: MIT

An MCP server that lets an LLM understand any tabular data file: point it at a CSV, Parquet, Excel or JSON file and get schema, distributions, data-quality flags and dtype suggestions back as structured JSON.

Stop pasting df.head() and df.info() into chat. Ask your assistant "profile sales.csv" and it reads the file itself, then tells you what is in it, what is wrong with it, and how to load it more efficiently.

data-profiler-mcp demo: one prompt returns severity-ranked data-quality flags and a memory-saving dtype plan

Works with Claude Desktop, Claude Code, Cursor, or any MCP-compatible client.

Features

Seven focused tools, all returning clean JSON:

Tool	What it does
`profile_dataset`	One-call overview: shape, memory, missing-value summary, duplicate rows, a per-column summary, and plain-language quality flags.
`preview_data`	The first / last / a random sample of `n` rows as real records.
`column_stats`	Deep dive on one column: full percentiles, skew/kurtosis, outliers (IQR), a histogram, or top values + string lengths for text.
`detect_quality_issues`	A data-quality audit: duplicates, high-missing and constant columns, numbers stored as text, mixed-type columns, whitespace padding, likely IDs, grouped by severity.
`suggest_dtypes`	Memory-saving / type-fixing recommendations (text to numeric, low-cardinality to `category`, integer/float downcasting) with estimated savings.
`compare_datasets`	Diff two files: added/removed columns, dtype changes, row-count delta, and per-column null-rate and mean side by side.
`correlation_matrix`	Correlations between numeric columns (Pearson / Spearman / Kendall): pairs ranked by strength, multicollinearity flags at \|r\| >= 0.9, and target-vs-rest ranking via `column`.

Supported formats: CSV, TSV, Parquet, Excel (.xlsx/.xls), JSON and JSON Lines. Large files are read up to a row cap and clearly flagged as sampled.

No dataset at hand? examples/sample.csv is a small sales export with deliberate quality issues (missing regions, a duplicate row, a constant column, whitespace padding) -- ask your assistant to "profile examples/sample.csv" and see what it flags.

Related MCP server: acb-tax-mcp

Install

No install needed to try it: open the Glama server page and use Try in Browser to call the tools against a sandbox (the repo ships examples/sample.csv at /app/examples/sample.csv to profile).

Requires Python 3.10+.

# with uv (recommended)
uv tool install data-profiler-mcp

# or with pip
pip install data-profiler-mcp

Or run it straight from source without installing:

git clone https://github.com/haiiibin/data-profiler-mcp
cd data-profiler-mcp
uv run data-profiler-mcp

Configure your client

Claude Desktop

Edit claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\) and add:

{
  "mcpServers": {
    "data-profiler": {
      "command": "data-profiler-mcp"
    }
  }
}

Running from source instead of installing? Point it at the checkout:

{
  "mcpServers": {
    "data-profiler": {
      "command": "uv",
      "args": ["--directory", "/absolute/path/to/data-profiler-mcp", "run", "data-profiler-mcp"]
    }
  }
}

Restart Claude Desktop and the tools appear under the plug icon.

Claude Code

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

Usage

Once connected, just talk to your assistant:

"Profile ~/data/sales_2025.csv and tell me what's in it."
"Are there any data-quality problems in customers.parquet?"
"Show me 20 random rows from events.jsonl."
"Give me full stats for the revenue column, including outliers."
"How can I shrink this DataFrame's memory usage?"
"What changed between snapshot_jan.csv and snapshot_feb.csv?"

Example: `profile_dataset`

{
  "file": { "name": "sample.csv", "format": "csv", "size_human": "14.2 KB" },
  "shape": { "rows": 201, "columns": 13, "sampled": false },
  "memory_usage_human": "78.4 KB",
  "missing_summary": { "total_missing_cells": 561, "pct_missing": 21.5, "columns_with_missing": 3 },
  "duplicate_rows": { "count": 1, "pct": 0.5 },
  "columns": [
    {
      "name": "price", "dtype": "float64", "inferred_type": "float",
      "non_null": 201, "null": 0, "unique": 51,
      "stats": { "min": 0.0, "max": 100000.0, "mean": 521.3, "median": 24.0 }
    }
  ],
  "quality_flags": [
    "[high] empty_col: Column is entirely empty (all values missing).",
    "[warning] const: Column holds a single constant value; it carries no information.",
    "[warning] numeric_text: Every value parses as a number but the column is stored as text."
  ]
}

Example: `detect_quality_issues`

{
  "issue_count": 8,
  "severity_counts": { "high": 2, "warning": 4, "info": 2 },
  "issues": [
    { "column": "empty_col", "issue": "all_missing", "severity": "high",
      "detail": "Column is entirely empty (all values missing)." },
    { "column": "numeric_text", "issue": "numeric_stored_as_text", "severity": "warning",
      "detail": "Every value parses as a number but the column is stored as text." }
  ]
}

How it works

The server is built on FastMCP and reads files with pandas (plus pyarrow for Parquet and openpyxl for Excel). Every tool returns a plain, JSON-serializable dict, with NumPy scalars, NaN/inf and timestamps normalized so the output is safe to hand straight back to a model. Nothing is written to disk and no data leaves your machine.

Development

uv venv
uv pip install -e ".[dev]"
uv run pytest

License

MIT. See LICENSE.

Available Tools

7 tools

column_statsA

Deep statistical dive on a single column.

For numeric columns: min/max, mean, std, a full set of percentiles (p1/p5/q1/median/q3/p95/p99), skewness, kurtosis, zero and negative counts, an IQR-based outlier count with bounds, and a 10-bin histogram. For datetime columns: the min and max timestamp. For text/categorical columns: the top values with counts and percentages, plus string-length statistics.

Reach for this after profile_dataset when one column needs closer inspection. Raises an error listing the available columns if column is not found.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`column`	Yes
`max_rows`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It thoroughly explains the output for numeric, datetime, and text columns, and discloses error behavior. As a read-only analysis tool, no destructive actions are implied, but it could explicitly state that no modifications are made.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two well-structured paragraphs. The first sentence front-loads the purpose, followed by detailed bullet points. Every sentence adds value, and there is no redundancy or wasted words.

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?

Despite lacking an output schema, the description provides a comprehensive overview of the returned statistics for each column type. It also covers error behavior. For a focused single-column analysis tool, this level of detail is complete and sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meanings. It only mentions the 'column' parameter in error context but fails to explain 'path' and 'max_rows'. This is a significant gap for a tool with 3 parameters.

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 as a 'deep statistical dive on a single column' and details the statistics for different column types. It distinguishes from sibling tool 'profile_dataset' by suggesting usage after it for closer inspection, providing specificity and differentiation.

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 explicitly says to use 'after profile_dataset when one column needs closer inspection' and mentions error behavior when column is not found. While clear context is provided, there is no explicit exclusion of other sibling tools or when-not usage.

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

compare_datasetsA

Diff two tabular files: what changed between version A and version B.

Reports the row-count delta, columns added or removed in B, dtype changes on shared columns, and per-column null-rate (and, for numeric columns, mean) for both files side by side.

Use this to compare two snapshots of the same dataset, validate a data pipeline's output against a baseline, or check what a transformation changed.

ParametersJSON Schema

Name	Required	Description	Default
`path_a`	Yes
`path_b`	Yes
`max_rows`	No

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It explains what the tool reports but does not disclose limitations, performance characteristics, or side effects (e.g., whether it loads entire files into memory).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: purpose, output details, use cases. It is front-loaded with the key verb and resource, and every sentence adds value without redundancy.

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 no output schema, the description explains the return values in reasonable detail (deltas, column changes, etc.). However, it does not mention how max_rows affects the results or the output format (e.g., a structured table).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage. The description implies path_a and path_b are the files to diff but does not explain the max_rows parameter or provide details on expected formats or constraints.

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: 'Diff two tabular files' and lists specific output metrics (row-count delta, column changes, dtype changes, null rates, means). This distinguishes it from sibling tools like column_stats or preview_data which focus on single datasets.

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?

Explicitly provides use cases: comparing snapshots, validating data pipeline baselines, checking transformations. While it doesn't mention when not to use it or name alternatives, the intended contexts are clear.

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

correlation_matrixA

Correlations between numeric columns, ranked by strength.

Computes pairwise correlations across all numeric columns (pearson by default; spearman or kendall for rank-based relationships) and returns pairs ranked by absolute correlation, a high_correlation_pairs list (|r| >= 0.9, a multicollinearity signal when preparing features for modeling), and the full matrix when there are 15 or fewer numeric columns. Pass column to instead rank how strongly every other numeric column correlates with that one, for example a target variable. Constant columns are excluded and listed.

Use this when the user is selecting features for a model, hunting redundant columns, or asking what moves together with a numeric outcome.

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`column`	No
`method`	No	pearson
`max_rows`	No

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and meets it: it discloses the default method (pearson), ranking by absolute correlation, the 0.9 threshold for high_correlation_pairs, the conditional full-matrix output for 15 or fewer numeric columns, and the exclusion/listing of constant columns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a one-line summary and expands into compact, purposeful detail. Every sentence adds value—method options, ranking behavior, threshold, matrix condition, constant columns, and usage context—without padding.

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 no output schema, the description explains return values well (pairs, high_correlation_pairs, conditional matrix, constants). However, max_rows is never addressed, so its effect is unclear; this is a small gap in an otherwise complete profile.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds strong semantics for method (pearson/spearman/kendall) and column (target-variable ranking), but it does not explain path or max_rows, leaving two of four parameters under-specified.

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 and resource—'Correlations between numeric columns, ranked by strength'—and then explains pairwise computation, ranking, and optional target-column behavior. This clearly differentiates correlation_matrix from the profiling, preview, and stats sibling tools.

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?

It explicitly states when to use it: 'when the user is selecting features for a model, hunting redundant columns, or asking what moves together with a numeric outcome.' It does not explicitly name alternatives to avoid, but the guidance is clear and actionable.

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

detect_quality_issuesA

Run a focused data-quality audit and return issues grouped by severity.

Detects duplicate rows, all-missing and high-missing columns, constant columns, likely identifier columns, numbers stored as text, dates stored as text, columns mixing numeric and text values, leading/trailing whitespace, and empty (whitespace-only) strings. Each issue carries a column (or null for table-level), an issue code, a severity (high/warning/info), and a plain-language explanation.

Use this when the user cares specifically about cleanliness, is preparing data for modeling, or asks "is anything wrong with this data?".

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`max_rows`	No

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, but the description details the types of issues detected and the output structure (column, issue code, severity, explanation). It does not cover performance or modification (non-destructive implied), but it is transparent about the behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the summary, then lists issues, then usage guidance. Every sentence adds value with no redundancy.

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 complexity (many issue types) and lack of output schema, the description adequately covers the purpose, input, and output format. It is missing parameter details, but overall it is fairly complete for the tool's scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the description does not explain the parameters (path, max_rows). The user cannot infer what 'path' refers to or how 'max_rows' affects the audit. This is a critical gap.

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 uses a specific verb ('Run a focused data-quality audit') and resource ('return issues grouped by severity'), and lists specific checks (duplicate rows, missing columns, etc.), clearly distinguishing it from sibling tools like profile_dataset or preview_data.

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 explicit use cases: 'when the user cares specifically about cleanliness, is preparing data for modeling, or asks 'is anything wrong with this data?'. It does not explicitly mention when not to use or alternatives, but the guidance is clear and helpful.

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

preview_dataA

Peek at actual rows of a data file.

Returns n rows (capped at 100) as records. mode selects which rows: head (default), tail, or sample (random). Use this to see real example values rather than just statistics, for example to check formatting, encodings, or how a specific column looks in practice.

ParametersJSON Schema

Name	Required	Default
`n`	No
`mode`	No	head
`path`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description takes on full burden, disclosing n capped at 100, mode options (head/tail/sample), and purpose. No side effects mentioned but likely none; adequate transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise, front-loaded sentences with no fluff; every word adds value.

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 3 parameters, no output schema, the description covers usage, parameters, and context adequately. Could mention return format explicitly but already covered.

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?

Schema coverage is 0% but description explains n (number of rows, capped at 100) and mode (with defaults and options), adding meaning beyond raw schema types. Path is implicit but clear.

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 peeks at actual rows of a data file, distinguishing it from siblings like column_stats or profile_dataset by emphasizing real values instead of statistics.

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?

It explains when to use (to see real example values for formatting, encodings, etc.) but does not explicitly state when not to use or list alternatives, though context is clear.

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

profile_datasetA

Profile a tabular data file in one call: the fastest way to understand a dataset.

Reads the file at path (CSV, TSV, Parquet, Excel or JSON/JSONL, detected from the extension) and returns a structured overview:

file metadata (format, size),
shape (row and column counts, and whether the profile was sampled),
total memory footprint,
a missing-value summary and a duplicate-row count,
a per-column summary (dtype, inferred type, null %, unique %, sample values, and basic stats for numeric/datetime columns), and
a list of plain-language data-quality flags.

Use this first whenever a user points you at a data file and wants to know what is in it. max_rows caps how many rows are read (default: up to one million); the result flags when the file was larger and the stats are a head sample. Pass 0 to remove the cap entirely.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`max_rows`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

In the absence of annotations, the description fully carries the burden. It discloses that it reads the file, detects format, returns a structured overview, and describes the sampling behavior controlled by max_rows. It does not mention potential side effects (likely none) or performance limitations.

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 lead sentence, then bullet-like list. It is appropriately sized for the tool's complexity, though could be slightly more concise by merging some bullet points.

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?

Despite no output schema, the description enumerates all major return categories: file metadata, shape, memory, missing values, duplicate count, per-column summary, and data-quality flags. For a two-parameter tool, this is fully complete.

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?

Schema description coverage is 0%, but the description explains path's role as 'Reads the file at path' and max_rows adds meaning: 'caps how many rows are read (default: up to one million); pass 0 to remove the cap entirely.' This adds value beyond the schema's type and title.

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 'Profile a tabular data file' and lists specific outputs (file metadata, shape, memory, missing values, column summary, flags). It distinguishes from sibling tools like preview_data and column_stats by emphasizing it's the fastest way to understand a dataset in one call.

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?

Explicitly recommends 'Use this first whenever a user points you at a data file and wants to know what is in it.' This provides clear when-to-use guidance, though it doesn't explicitly mention alternatives or when not to use.

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

suggest_dtypesA

Recommend more memory-efficient or more-correct column dtypes.

For each column, proposes a better dtype when one exists: text that is fully numeric to a numeric type, low-cardinality text to category, and oversized integer/float columns downcast to smaller types. Reports per-column and total estimated memory savings.

Use this to help a user shrink a DataFrame's memory footprint or fix columns that were loaded with the wrong type.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`max_rows`	No

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Details specific behaviors: proposing numeric conversions, category for low-cardinality, downcasting, and reporting savings. Covers key expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three succinct sentences with no redundancy. Front-loaded with purpose, then behavior, then usage.

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?

Covers purpose, usage, and behavior well for a simple tool. Minor gap: no parameter explanations, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description should parameter details. It does not explain 'path' or 'max_rows', leaving their roles ambiguous.

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 recommends memory-efficient or correct column dtypes, distinguishing it from sibling tools that handle stats, quality, or profiling.

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?

Provides explicit use cases: shrink memory footprint or fix wrong types. No exclusions or alternatives mentioned, but context is clear.

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.

1 tool updatev0.3.0Aug 21, 2026
- Addedcorrelation_matrix
6 tool updatesv0.1.0Jul 11, 2026
- First observedcolumn_stats
- First observedcompare_datasets
- First observeddetect_quality_issues
- First observedpreview_data
- First observedprofile_dataset
- First observedsuggest_dtypes

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-09-09 18:10 across 7 tools

Disambiguation4/5

Most tools target a clearly different concern: overview profiling, raw row preview, single-column statistics, quality audit, dtype suggestions, dataset comparison, and correlation analysis. There is some overlap between profile_dataset and detect_quality_issues since both surface missing-data and duplicate information, but the descriptions make the intended use cases distinct enough to avoid serious misselection.

Naming Consistency4/5

Most names follow a verb_noun pattern: profile_dataset, preview_data, detect_quality_issues, suggest_dtypes, compare_datasets. column_stats and correlation_matrix are noun-based exceptions, but they are still short, descriptive, and readable, so the overall naming is consistent without being rigid.

Tool Count5/5

Seven tools is well-scoped for a data profiling server. Each tool covers a meaningful phase of exploration—high-level profiling, previewing rows, deep-diving columns, quality checks, dtype optimization, comparison, and correlation—without redundancy or bloat.

Completeness5/5

The tool surface covers the main data-profiling lifecycle: understand overall structure, inspect actual values, drill into a specific column, audit quality issues, suggest type fixes, compare datasets, and analyze correlations. There are no obvious dead ends or critical missing operations for the stated purpose.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

OleanderOAuth
dev.oleander
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
Databases Data Platforms Data Visualization
2
GoldenFlow A
io.github.benseverndev-oss
Standardize, reshape, and normalize messy data — CSV, Excel, Parquet, S3, databases.
Data Platforms Databases
21
excel-spreadsheet-xlsx-csv A
io.github.theluckystrike
Open, inspect, filter, edit and convert xlsx and csv files from your AI chat. Processing is local.
Workplace & Productivity File Systems
131
stagenth · 数据工具箱 A
com.stagenth
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Databases Data Platforms File Systems
62

Related MCP Servers

Claude Data Buddy
Research & Data Developer Tools Data Platforms
iramk11
F
license
Not graded
quality
D
maintenance
Enables conversational analysis of CSV and Parquet files through natural language, providing statistics, summaries, data type information, and comprehensive multi-step data analysis.
Updated 9 months ago (2025-12-08 05:45 UTC)
-
acb-tax-mcp
Finance Research & Data
haiiibin
A
license
A
quality
A
maintenance
An MCP server that computes Canadian adjusted cost base (ACB) and capital gains from trade history, including average-cost tracking and superficial-loss detection, returning structured JSON.
Updated 20 days ago (2026-08-22 05:29 UTC)
7
MIT
mcp-pandas
devantage
A
license
A
quality
B
maintenance
Enables data analysis on CSV/Excel files using pandas. Supports profiling, column interpretation, sandboxed code execution, and interactive chart generation.
Updated 2 months ago (2026-07-20 09:49 UTC)
4
1
MIT
mcp-data-profiler
Research & Data Databases File Systems
Ridadata
A
license
A
quality
A
maintenance
MCP server that profiles local data files (CSV, Parquet, JSON, Excel) and returns compact structured summaries with data-quality flags, enabling AI agents to understand datasets without seeing raw rows.
Updated a month ago (2026-08-07 22:51 UTC)
1
1
MIT

data-profiler-mcp

Features

Install

Configure your client

Claude Desktop

Claude Code

Usage

Example: profile_dataset

Example: detect_quality_issues

How it works

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Example: `profile_dataset`

Example: `detect_quality_issues`