Dedupe, flatten and clean messy JSON rows (emails, phones, URLs, HTML) in one call, as JSON or CSV.
Scored across 2 tools
clean_rows performs all data processing while list_capabilities only returns metadata; their purposes are entirely distinct with no overlap.
Both tools use snake_case with a clear verb_noun pattern (clean_rows, list_capabilities), consistent and predictable.
Two tools is on the thin side for a server named Dataset Cleaner & Exporter; while the single cleaning tool is comprehensive, only one operational tool plus a meta tool may feel sparse.
The cleaning tool covers deduplication, flattening, normalization, export to CSV/rows, and returns summary metrics; minor gaps like a preview or separate export formats exist but are not critical.
Deduplicates, flattens and cleans a list of JSON rows in one call and returns spreadsheet-ready rows (or CSV text) plus a summary with exact counts: rows in, rows added by expansion, duplicates removed, rows dropped by maxItems, rows out, the final column list, per-column fill rates and warnings. Steps, in order: optionally explode one array field into one row per entry; flatten nested objects into columns (address.city becomes address_city); trim text; lowercase valid emails; reduce phone numbers to digits with any leading +; lowercase URL hosts and drop the trailing slash; optionally strip HTML and turn numeric or true/false text into numbers and booleans; blank text becomes null; keep, remove or rename columns; then remove duplicates (normalized by default, comparing the whole row unless dedupKeys is set) keeping the most complete row. Deterministic, no AI, nothing guessed. Use it on scraped leads, CRM exports or API results before loading them anywhere. There is a row limit per call (see list_capabilities); split bigger lists across several calls.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | The rows to clean. Each row is a JSON object; keys may differ between rows and values may be nested. | |
| flatten | No | Default true. Turn nested objects into flat columns. Arrays become one JSON-text cell. | |
| maxItems | No | Optional cap: read at most this many rows and return at most this many. 0 (default) means no cap. | |
| dedupKeys | No | Fields that identify a duplicate, for example ["Email"]. Empty compares the whole row. Use the final column names: flattened (Details_founded) and renamed. Exact and case-sensitive. Rows where every key is empty count as duplicates of each other. | |
| dedupMode | No | How duplicates are found. normalized (default) ignores case and whitespace; exact needs identical values; fuzzy also merges near-duplicates (up to 100 rows and 1000 characters of key text, so name a short field in dedupKeys); none keeps every row. | |
| stripHtml | No | Default false. Remove HTML tags and decode common entities in text. | |
| cleanFields | No | Default true. Normalize emails, phone numbers and URLs, detected by field name or value shape. | |
| coerceTypes | No | Default false. Turn "42" into 42 and "true" into true. Leading-zero values like "007" stay text. | |
| emptyToNull | No | Default true. Blank text becomes null. | |
| keepStrategy | No | Which duplicate survives: most_complete (default, fewest empty fields), first or last. | |
| outputFormat | No | json (default) returns rows; csv returns the same result as CSV text in "csv" instead. | |
| columnsToKeep | No | Keep only these columns (flattened names). Takes priority over columnsToRemove. | |
| columnRenameMap | No | Rename columns after keep/remove, as ["oldName:newName"] or {"oldName":"newName"}, for example {"Details_founded":"founded"}. | |
| columnsToRemove | No | Drop these columns (flattened names). Ignored if columnsToKeep is set. | |
| dropEmptyFields | No | Default false. Remove null and empty fields from each row. | |
| expandArrayField | No | Optional. One top-level array field (for example "offers") to explode into one row per entry, repeating the other fields. Object entries become columns. The expanded total must stay within the row limit. | |
| flattenSeparator | No | Joins nested key paths when flattening. Default "_". | |
| similarityThreshold | No | Fuzzy mode only. 0.5 to 0.99, default 0.9. Higher is stricter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does so: it discloses the exact ordered pipeline (explode, flatten, trim, lower emails, phone normalization, URL host/slash handling, type coercion, empty-to-null, column ops, dedup), the default dedup normalization and 'most complete row' survival rule, determinism, and the per-call row limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and return shape are front-loaded, followed by the pipeline then usage notes, so an agent can stop reading early. It is dense rather than padded, though the long middle sentence enumerating every transform is heavier than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter, annotation-free tool with no output schema, the description covers the gaps: it describes the returned summary fields and counts, the warning behavior, determinism, and the size constraint. Nothing required to invoke it correctly is obviously missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds real semantics beyond the schema: the order in which steps run, that dedup compares the whole row unless dedupKeys is set and that key names must be final flattened/renamed names, and how blank-vs-null and type coercion interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific set of verbs and resource ('Deduplicates, flattens and cleans a list of JSON rows') and states the return shape (spreadsheet-ready rows/CSV plus a summary). This is unmistakably distinct from the only sibling, list_capabilities, without needing to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete usage context ('scraped leads, CRM exports or API results before loading them anywhere') and points at list_capabilities for the row limit, plus the workaround of splitting large lists across calls. It lacks an explicit 'when not to use' or an alternative-tool comparison, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the exact cleaning rules (how emails, phone numbers and URLs are detected and normalized), the dedup modes and keep strategies, the order the steps run in, and the maximum rows per call. Call this first if you are unsure how a field will be treated. Free, processes no data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present the description carries the full load, and it does disclose real behavioral traits: the call is free and processes no data (i.e., side-effect-free introspection). It also enumerates the knowledge returned, which is more than a restatement of the name. It stops short of describing the output format or how to act on the values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what is returned and followed by the actionable 'call this first' guidance. Every clause adds information (rule types, dedup modes, step order, row cap, cost, side effects) with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema introspection tool, the description is sufficient: it explains what knowledge is exposed, reassures the agent there is no data-processing cost, and gives a usage trigger. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema has additionalProperties false, so there is nothing to document. Baseline 4 applies; the description correctly does not waste space on nonexistent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Returns) and an enumerated resource: cleaning rules for emails/phones/URLs, dedup modes and keep strategies, step order, and max rows per call. The trailing 'Free, processes no data' cleanly separates it from the sibling clean_rows, which does process data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger, 'Call this first if you are unsure how a field will be treated', which tells the agent when to reach for it. It never names clean_rows as the alternative or states when to skip this tool, so the routing is implied rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
clean_rowslist_capabilitiesClean, filter and reshape JSON rows in one call: 26 transforms, 25 filters, sort, dedupe, limit.
Standardize, reshape, and normalize messy data — CSV, Excel, Parquet, S3, databases.
Fuzzy entity resolution and dedupe for names, addresses, and company records. $0.02/call via x402.
Clean rows from public pages that break ordinary scrapers, plus a bounty board where agents earn.