DataClean MCP

Overview Schema Source Related Servers Discussions Admin

validate_schema

Read-onlyIdempotent

Checks every parsed row against a supplied schema to flag type, required, unique, range, enum, and pattern errors with source row numbers.

Instructions

Check every row of a table against a schema, after the same parsing clean_table applies.

schema: {"columns": {"id": {"type": "integer", "required": true, "unique": true}, "email": {"type": "email", "required": true}, "amount": {"type": "decimal", "min": 0, "max": 100000}, "signup": {"type": "date", "min": "2020-01-01"}, "status": {"enum": ["active", "churned"]}, "sku": {"type": "text", "pattern": "[A-Z]{3}-\d{4}", "max_length": 8}}, "strict_columns": false} Rules: type, required, unique (case-insensitive), min/max (numbers and dates), min_length/max_length, enum (case-insensitive), pattern (full match; nested quantifiers are refused). Column names match case-insensitively. strict_columns flags columns that are not in the schema. Errors carry the source row number; valid is true only with zero errors. profile_table returns a suggested schema to start from.

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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "schema": "<schema>"
    },
    "name": "validate_schema"
  }
}

Input Schema

Name	Required	Description	Default
`rows`	No
`sheet`	No
`schema`	Yes
`content`	No
`delimiter`	No
`date_order`	No
`has_header`	No
`header_row`	No
`max_errors`	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.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, and the description adds substantial behavior: which rules are enforced, case-insensitive column and enum matching, full-match patterns with nested quantifiers refused, error row numbers, and the exact condition for `valid` being true. The notable gap is max_errors (default 500) — truncation behavior on error-heavy tables is never disclosed, which is exactly the kind of trait an agent needs to interpret results.

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 purpose sentence is front-loaded and the remainder is organized into labeled blocks (schema, rules, input, parsing) that make a dense 13-parameter surface scannable. Length is largely justified by the complexity, though the inline JSON example is bulky and the `types` sentence is wasted space given it maps to no parameter.

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?

An output schema exists, so return values needn't be explained, yet the description still usefully clarifies `valid` and error row numbers. For a 13-parameter tool with a nested free-form schema object, it covers nearly everything an agent needs, missing only max_errors semantics and containing one phantom parameter (`types`) that undercuts completeness.

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?

With 0% schema coverage across 13 parameters, the description carries the full burden and mostly succeeds: it explains the three mutually exclusive input modes, delimiter/sheet/header handling, locale and date-order fallbacks, phone_country, null_values, and documents the free-form `schema` object with a full example plus rule list. Two defects hold it back — max_errors is never mentioned, and `types` is described in detail but does not exist as a property in the input schema, which can send an agent down a dead end.

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?

States a specific verb and resource (check every row of a table against a schema) and pins the scope with 'after the same parsing clean_table applies'. It also implicitly separates itself from profile_table by noting that tool produces a suggested schema rather than validating one, so an agent can choose between the two siblings 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?

The mention that 'profile_table returns a suggested schema to start from' gives a clear entry-point workflow, and the reference to clean_table's parsing clarifies the relationship between the two tools. There is no explicit when-not-to-use guidance (e.g. when to prefer clean_table or normalize_values instead), so it stops short of full routing guidance.

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

Deploy Server