DataClean MCP

Overview Schema Source Related Servers Discussions Admin

clean_table

Read-onlyIdempotent

Clean and type tabular data from CSV, TSV, JSON, or XLSX, then report every change and flagged unconverted value so ambiguous inputs are handled transparently.

Instructions

Return a clean, typed copy of a table, with a report of every change and every value left unconverted.

Text: NUL/control/zero-width characters removed, mojibake repaired (CafÃ© -> Café), Unicode NFC, spaces collapsed and trimmed. Numbers: plain decimals (1.250,50 € -> 1250.50; (45) -> -45; 1.250,50- -> -1250.50). Dates: ISO 8601. Booleans: true/false. Emails: domain lowercased. Phones: E.164. IBAN: compact uppercase. Values that do not fit the column type are kept as they were (on_invalid='null' empties them) and listed in flags with their source row.

Args: output_format: csv (default) | tsv | json | jsonl | xlsx (typed cells; returned only as content_base64). header_style: keep | snake (Fecha de alta -> fecha_de_alta). columns: keep only these columns, in order. dedupe: none | exact | ignore_case, over all columns or dedupe_keys; the first occurrence is kept. drop_empty_columns: remove columns with no values. output_delimiter: for csv output. formula_guard: prefix text cells starting with = + - @ with ' in CSV so spreadsheets do not run them.

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": "clean_table"
  }
}

Input Schema

Name	Required	Default
`rows`	No
`sheet`	No
`types`	No
`dedupe`	No	none
`columns`	No
`content`	No
`delimiter`	No
`date_order`	No
`has_header`	No
`header_row`	No
`on_invalid`	No	keep
`dedupe_keys`	No
`null_values`	No
`fix_mojibake`	No
`header_style`	No	keep
`formula_guard`	No
`number_locale`	No
`output_format`	No	csv
`phone_country`	No
`content_base64`	No
`output_delimiter`	No	,
`drop_empty_columns`	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.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), yet the description still adds real behavior: unconvertible values are preserved and listed in `flags` with their source row, on_invalid='null' instead empties them, xlsx is returned only as content_base64 with typed cells, and formula_guard prefixes = + - @ with a quote to prevent spreadsheet execution. What it does not disclose is the shape of the change report or how the flags list is surfaced to the caller, which the output schema presumably covers.

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 one-line purpose is front-loaded, followed by grouped blocks (transformations, Args, Input, Parsing), so an agent can scan rather than read linearly. It is dense but nearly every clause carries information about a 22-parameter surface; the indented pseudo-docstring layout is slightly harder to parse than a flat list but wastes little.

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?

For a high-complexity, 22-parameter, zero-schema-coverage tool, the definition is unusually complete: input source selection, parsing ambiguity resolution, per-column type forcing, invalid-value policy, and output formats are all addressed, and return-value shape is delegated to the existing output schema. The remaining gap is sibling routing — nothing tells an agent why it would pick this over normalize_values or validate_schema.

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?

With 22 parameters and 0% schema description coverage, the description carries the entire burden and largely succeeds — it explains enum-like values and concrete formats for output_format, header_style (including a worked 'Fecha de alta -> fecha_de_alta' example), dedupe/dedupe_keys, delimiter auto-detection, header_row, number_locale (with the 1,250 ambiguity called out), date_order, phone_country, null_values, and the allowed type names for `types`. Only `fix_mojibake` lacks a named explanation, though mojibake repair is described in the prose.

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 opening sentence names a specific verb and artifact — 'Return a clean, typed copy of a table, with a report of every change and every value left unconverted' — and the following blocks make the transformation scope (text repair, numeric/date/phone/IBAN coercion, dedupe, header normalization) concrete enough to separate it from diagnostic siblings like profile_table and validate_schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer 'use this to clean/coerce tabular input', and the 'Input (exactly one)' note usefully encodes the mutual-exclusion rule for content/content_base64/rows. But the closest sibling, normalize_values, is never mentioned, so there is no explicit guidance on when to clean-and-return a table versus when to normalize values in place, and no stated preconditions or when-not-to-use cases.

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

Deploy Server