DataClean MCP

Overview Schema Source Related Servers Discussions Admin

profile_table

Read-onlyIdempotent

Profile CSV, XLSX, or JSON tables without changing them to detect column types, nulls, duplicates, encoding issues, and ambiguous values before cleaning or validation.

Instructions

Profile a table: what each column really contains and what is wrong with it, without changing it.

Returns the detected encoding/delimiter/header, per-column type, nulls, distinct values, min/max, number locale, date order, currency, examples and notes (leading-zero IDs, formula-injection cells, ambiguous dates or numbers, mixed separators), table issues (ragged rows, NUL bytes, duplicate headers, title rows), exact duplicate rows, the first 50 flagged cells and a suggested schema for validate_schema.

Input (exactly one): content (CSV/TSV/JSON text), content_base64 (file bytes: .xlsx, or CSV in any encoding),
rows (JSON list of objects or of lists). delimiter: auto-detected (, ; tab |). sheet: Excel sheet name (default
the first). has_header: false when the first row is data. header_row: 1-based row of the header (default auto,
skipping title rows above it).
Parsing: number_locale 'eu' (1.234,56) or 'us' (1,234.56) settles values like 1,250 (auto from the column
otherwise). date_order 'dmy' or 'mdy' settles dates like 03/04/2026 (auto from the column otherwise).
phone_country (ISO-2, e.g. ES, US, GB) converts national phone numbers to E.164. null_values: extra strings
read as empty (NULL, N/A, -, #N/A and similar are already). types: force a type per column, e.g.
{"zip": "text", "amount": "decimal"}; types are text, integer, decimal, boolean, date, datetime, email, url,
phone, iban.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "profile_table"
  }
}

Input Schema

Name	Required	Description	Default
`rows`	No
`sheet`	No
`types`	No
`content`	No
`delimiter`	No
`date_order`	No
`has_header`	No
`header_row`	No
`null_values`	No
`number_locale`	No
`phone_country`	No
`content_base64`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/closed-world, so safety is covered; the description adds real value beyond that by disclosing what gets detected automatically (encoding, delimiter, header, locale, date order), what is flagged (leading-zero IDs, formula-injection cells, NUL bytes, ragged rows), and the hard cap of 'the first 50 flagged cells'. It does not discuss size limits, performance, or how ambiguity is resolved when auto-detection guesses wrong.

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?

Purpose is front-loaded in one sentence, then inputs are grouped under 'Input' and 'Parsing' labels, so the density is navigable despite the length. The long paragraph of return fields overlaps with the output schema and is the main trimming candidate.

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?

For a 12-parameter tool with zero schema descriptions, the definition covers every input mode, default, and override, plus the failure signals an agent needs to interpret results. Return-value detail is arguably redundant given the output schema, but nothing an agent needs in order to call it correctly is missing.

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 coverage is 0%, so the description carries the full burden and does so thoroughly: it states that exactly one of content/content_base64/rows must be supplied, gives accepted formats per mode (.xlsx, any-encoding CSV), explains delimiter/header_row/sheet defaults, and disambiguates number_locale and date_order with concrete examples (1.234,56 vs 1,234.56; 03/04/2026). It even enumerates the legal values for types, which the schema leaves as an unconstrained string map.

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 first sentence gives a specific verb+resource ('Profile a table') plus the distinguishing constraint 'without changing it', and the return list ('per-column type, nulls, distinct values...') makes clear this is a diagnostic read, not a repair. It also names the sibling it feeds ('a suggested schema for validate_schema'), so an agent can separate it from validate_schema and clean_table without opening a schema.

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?

'without changing it' implicitly routes mutation work to clean_table, and the handoff to validate_schema establishes the inspection-before-validation workflow. It does not state explicit exclusions or say when profiling should be skipped, so it stops short of the top tier.

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

Deploy Server