Convert and clean tables: CSV, JSON, dedupe, stats. Free.
Scored across 4 tools
Each tool targets a clearly different table operation (cleaning, computing a single column statistic, format conversion, splitting a column), and the descriptions explicitly state what not to use and which alternative to choose. There is no realistic overlap that would cause misselection.
All names use snake_case and are readable, with three following a verb_noun pattern (clean_table, convert_table, split_column). column_stats breaks the pattern by being noun_noun, but the overall convention remains predictable.
Four tools is well-scoped for a focused table-manipulation server, and each tool earns its place without redundancy. The count supports a compact, purpose-built toolkit rather than an overstuffed API.
The surface covers core table preparation, conversion, column splitting, and simple single-column statistics. Common row-level operations like filtering, sorting, or joining tables are absent, but these are minor gaps relative to the stated formatting and cleaning focus.
Clean a table: trim whitespace in cells, drop fully empty rows, and optionally remove duplicate rows; returns the table in the same format with before/after row counts. Use when preparing messy pasted data. Do NOT use to change format; use convert_table.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The whole table as text, first row = header. CSV/TSV text (quoted cells allowed), or a JSON array of flat objects, e.g. "name,age\nAsha,30". | |
| trim | No | Trim leading/trailing whitespace in every cell. Default true. | |
| dedupe | No | Remove exact duplicate data rows, keeping the first. Default false. | |
| format | No | Format of 'data' and of the returned table: csv, tsv or json. Default csv. | |
| drop_empty_rows | No | Remove rows whose cells are all empty. Default true. |
| Name | Required | Description |
|---|---|---|
| text | Yes | The cleaned table as text in the input format. |
| rows_after | Yes | Data rows after cleaning (excluding header). |
| rows_before | Yes | Data rows before cleaning (excluding header). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond them: output preserves the input format and reports before/after row counts, which tells the agent the operation is non-shape-changing. It stops short of noting that cleaning never alters column structure or header handling, so not quite a 5.
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?
Front-loads the operation list in a single dense clause, then two short sentences for usage and the exclusion. No filler, and the most decision-relevant routing information (do not use for format conversion) is stated last but in one clause.
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?
With an output schema present, the description need not explain return values, and it still mentions the row-count summary. Purpose, scope, defaults implied by the schema, and the sibling alternative are all covered, so an agent has everything needed to call it correctly.
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 description coverage is 100%, so every parameter (trim, dedupe, format, drop_empty_rows, data) is already documented with defaults and the enum in the schema. The description restates the three cleaning behaviors but adds no format syntax or edge-case semantics beyond it, which is the expected baseline when the schema does the heavy lifting.
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?
Names a specific verb (clean) and resource (table) and enumerates the exact operations performed: trim whitespace, drop fully empty rows, optionally dedupe. It also explicitly distinguishes itself from convert_table, so an agent can separate it from the sibling without opening 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?
States the triggering context ('when preparing messy pasted data') and an explicit exclusion plus the alternative ('Do NOT use to change format; use convert_table'). Both the when and the when-not are present, which is the top of the scale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute one statistic over a single column: sum, avg, min or max (numeric, rounded to 2 dp, blanks ignored), count of non-empty cells, or the sorted distinct values. Use for quick answers like 'total of the price column'. Do NOT use to reshape the table; use split_column or convert_table.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Statistic: sum, avg, min, max (column must be numeric), count (non-empty cells) or distinct (unique values). | |
| data | Yes | The whole table as text, first row = header. CSV/TSV text (quoted cells allowed), or a JSON array of flat objects, e.g. "name,age\nAsha,30". | |
| column | Yes | Column to use: the exact header name (case-sensitive), or a 0-based column index as digits, e.g. "price" or "2". | |
| format | No | Format of 'data' and of the returned table: csv, tsv or json. Default csv. |
| Name | Required | Description |
|---|---|---|
| op | Yes | The statistic that was computed. |
| column | Yes | Header name of the column that was analysed. |
| result | Yes | Numeric result for sum/avg/min/max/count, or a sorted array of distinct string values for distinct. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description goes beyond that by disclosing rounding to 2 dp, blanks being ignored, count meaning non-empty cells, and distinct values being sorted. It stops short of noting error behavior for non-numeric input on sum/avg, which keeps it from a 5.
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?
Three compact sentences with the operation set front-loaded, followed by positive use case and the exclusion. No filler and no repetition of structured fields.
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?
With an output schema present, return-value explanation is unnecessary, and annotations carry the safety profile. The description supplies purpose, alternatives, and result semantics for a 4-parameter tool, leaving nothing an agent needs to call it correctly.
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 100%, so the baseline is 3. The description still adds semantics beyond the enum text: numeric results are rounded to 2 dp, blanks are ignored, count counts non-empty cells, and distinct returns sorted values. That is genuine value over the schema, though the op meanings largely overlap the enum descriptions.
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?
Names a specific operation (compute one statistic over a single column) and enumerates the exact supported ops (sum/avg/min/max/count/distinct). It also explicitly distinguishes itself from the sibling tools split_column and convert_table, so an agent can route without opening schemas.
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 positive guidance ('quick answers like total of the price column') and an explicit exclusion ('Do NOT use to reshape the table; use split_column or convert_table'). This is the when/when-not/alternative pattern at full strength.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a table from CSV, TSV or JSON into CSV, TSV, JSON (array of objects) or a Markdown table. Cell values are kept as text. Use when the user wants the same table in another format. Do NOT use to trim, dedupe or drop rows; use clean_table.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The whole table as text, first row = header. CSV/TSV text (quoted cells allowed), or a JSON array of flat objects, e.g. "name,age\nAsha,30". | |
| to_format | Yes | Output format: csv, tsv, json (array of objects keyed by header) or markdown (pipe table). | |
| from_format | Yes | Format of the input 'data': csv, tsv or json. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | Number of data rows (excluding the header). |
| text | Yes | The converted table as text in to_format. |
| columns | Yes | Number of columns in the header row. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: 'Cell values are kept as text', which tells the agent no type coercion or numeric parsing occurs. It stops short of describing malformed-input or header-handling behavior, so it is not exhaustive.
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?
Three short sentences, front-loaded with the conversion scope before the usage guidance and exclusion. The format enumeration partially duplicates the schema's enum descriptions, which is a minor redundancy, but every sentence still carries selection value.
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?
An output schema exists so return values need no explanation, and the annotations already cover the safety profile. What remains — what the tool does, when to use it, when not to, and what happens to cell values — is all present, leaving no meaningful gap for a 3-parameter conversion tool.
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 description coverage is 100% and both format parameters carry their own enum descriptions, so the schema does the heavy lifting — baseline 3. The description restates the accepted format sets but adds no syntax, default, or edge-case detail beyond what the schema already documents.
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 ('Convert') and resource ('a table'), then enumerates both input and output formats explicitly. It also names the sibling clean_table and the exact operations that belong to it, so an agent can distinguish this tool from its alternatives without opening any 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?
Gives an affirmative trigger ('Use when the user wants the same table in another format') and an explicit exclusion with an alternative ('Do NOT use to trim, dedupe or drop rows; use clean_table'). Nothing about tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split one column into several columns on a delimiter (e.g. 'full name' on a space), inserted in place; short rows are padded with empty cells. Returns the table in the same format. Use when one column packs several values. Do NOT use to clean or change format; use clean_table or convert_table.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The whole table as text, first row = header. CSV/TSV text (quoted cells allowed), or a JSON array of flat objects, e.g. "name,age\nAsha,30". | |
| column | Yes | Column to use: the exact header name (case-sensitive), or a 0-based column index as digits, e.g. "price" or "2". | |
| format | No | Format of 'data' and of the returned table: csv, tsv or json. Default csv. | |
| delimiter | Yes | Literal text to split on, e.g. " ", "-" or "|". | |
| new_names | No | Header names for the new columns; count must equal the maximum number of parts. Default <column>_1, <column>_2, ... |
| Name | Required | Description |
|---|---|---|
| text | Yes | The resulting table as text in the input format. |
| parts | Yes | Number of new columns the split produced. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description still adds non-obvious behavior: rows are split in place and short rows are padded with empty cells, which tells the agent what the output shape will be for ragged data.
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?
Front-loads the operation and its in-place/padding semantics, then the usage condition, then the exclusion, in four tight sentences 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?
With an output schema present and full annotation and schema coverage, the description only needs to frame purpose and routing, which it does; the padding note and 'returns the table in the same format' remove any residual ambiguity.
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 100%, so all five parameters, including the format enum and new_names default, are documented in the schema. The description restates the delimiter concept with examples but adds no format or naming guidance beyond it, so the baseline 3 applies.
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 and resource ('Split one column into several columns on a delimiter') with a concrete example ('full name' on a space). It names sibling tools it is not, so an agent can distinguish it from clean_table and convert_table without opening schemas.
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?
Explicit when-to-use ('Use when one column packs several values') plus an explicit exclusion with named alternatives ('Do NOT use to clean or change format; use clean_table or convert_table'). Both the positive and negative routing conditions are covered.
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_table14 fields changedInput schema / properties / data / descriptionPrevious value: -"The data for this request."New value: +"The whole table as text, first row = header. CSV/TSV text (quoted cells allowed), or a JSON array of flat objects, e.g. \"name,age\\nAsha,30\"."Input schema / properties / data / minLengthAdded value: +1Input schema / properties / dedupe / descriptionPrevious value: -"Set true to enable dedupe; false otherwise."New value: +"Remove exact duplicate data rows, keeping the first. Default false."Input schema / properties / drop_empty_rows / descriptionPrevious value: -"Set true to enable drop empty rows; false otherwise."New value: +"Remove rows whose cells are all empty. Default true."Input schema / properties / format / descriptionPrevious value: -"The format for this request."New value: +"Format of 'data' and of the returned table: csv, tsv or json. Default csv."Input schema / properties / format / enumAdded value: +[
+ "csv",
+ "tsv",
+ "json"
+]Input schema / properties / trim / descriptionPrevious value: -"Set true to enable trim; false otherwise."New value: +"Trim leading/trailing whitespace in every cell. Default true."Output schema / properties / cleaned_dataRemoved value: -{
- "description": "The cleaned table string with trimmed cells, empty rows dropped, and duplicate rows removed.",
- "type": "string"
-}Output schema / properties / rows_afterAdded value: +{
+ "description": "Data rows after cleaning (excluding header).",
+ "type": "integer"
+}Output schema / properties / rows_beforeAdded value: +{
+ "description": "Data rows before cleaning (excluding header).",
+ "type": "integer"
+}Output schema / properties / rows_droppedRemoved value: -{
- "description": "The number of empty rows that were dropped from the table.",
- "type": "integer"
-}Output schema / properties / rows_duplicatedRemoved value: -{
- "description": "The number of duplicate rows that were removed from the table.",
- "type": "integer"
-}Output schema / properties / textAdded value: +{
+ "description": "The cleaned table as text in the input format.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "cleaned_data"
-]New value: +[
+ "text",
+ "rows_before",
+ "rows_after"
+]column_stats18 fields changedInput schema / properties / column / descriptionPrevious value: -"The column for this request."New value: +"Column to use: the exact header name (case-sensitive), or a 0-based column index as digits, e.g. \"price\" or \"2\"."Input schema / properties / column / minLengthAdded value: +1Input schema / properties / data / descriptionPrevious value: -"The data for this request."New value: +"The whole table as text, first row = header. CSV/TSV text (quoted cells allowed), or a JSON array of flat objects, e.g. \"name,age\\nAsha,30\"."Input schema / properties / data / minLengthAdded value: +1Input schema / properties / format / descriptionPrevious value: -"The format for this request."New value: +"Format of 'data' and of the returned table: csv, tsv or json. Default csv."Input schema / properties / format / enumAdded value: +[
+ "csv",
+ "tsv",
+ "json"
+]Input schema / properties / op / descriptionPrevious value: -"The op for this request."New value: +"Statistic: sum, avg, min, max (column must be numeric), count (non-empty cells) or distinct (unique values)."Input schema / properties / op / enumAdded value: +[
+ "sum",
+ "avg",
+ "min",
+ "max",
+ "count",
+ "distinct"
+]Output schema / properties / avgRemoved value: -{
- "description": "The average of the values in the specified column.",
- "type": "number"
-}Output schema / properties / columnAdded value: +{
+ "description": "Header name of the column that was analysed.",
+ "type": "string"
+}Output schema / properties / countRemoved value: -{
- "description": "The number of values in the specified column.",
- "type": "integer"
-}Output schema / properties / distinctRemoved value: -{
- "description": "The number of distinct values in the specified column.",
- "type": "integer"
-}Output schema / properties / maxRemoved value: -{
- "description": "The maximum value in the specified column.",
- "type": "number"
-}Output schema / properties / minRemoved value: -{
- "description": "The minimum value in the specified column.",
- "type": "number"
-}Output schema / properties / opAdded value: +{
+ "description": "The statistic that was computed.",
+ "type": "string"
+}Output schema / properties / resultAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ ],
+ "description": "Numeric result for sum/avg/min/max/count, or a sorted array of distinct string values for distinct."
+}Output schema / properties / sumRemoved value: -{
- "description": "The sum of the values in the specified column.",
- "type": "number"
-}Output schema / requiredPrevious value: -[
- "sum",
- "avg",
- "min",
- "max",
- "count",
- "distinct"
-]New value: +[
+ "column",
+ "op",
+ "result"
+]convert_table13 fields changedInput schema / properties / data / descriptionPrevious value: -"The data for this request."New value: +"The whole table as text, first row = header. CSV/TSV text (quoted cells allowed), or a JSON array of flat objects, e.g. \"name,age\\nAsha,30\"."Input schema / properties / data / minLengthAdded value: +1Input schema / properties / from_format / descriptionPrevious value: -"The from format for this request."New value: +"Format of the input 'data': csv, tsv or json."Input schema / properties / from_format / enumAdded value: +[
+ "csv",
+ "tsv",
+ "json"
+]Input schema / properties / to_format / descriptionPrevious value: -"The to format for this request."New value: +"Output format: csv, tsv, json (array of objects keyed by header) or markdown (pipe table)."Input schema / properties / to_format / enumAdded value: +[
+ "csv",
+ "tsv",
+ "json",
+ "markdown"
+]Output schema / properties / columnsAdded value: +{
+ "description": "Number of columns in the header row.",
+ "type": "integer"
+}Output schema / properties / converted_dataRemoved value: -{
- "description": "The table data converted to the specified format.",
- "type": "string"
-}Output schema / properties / from_formatRemoved value: -{
- "description": "The original format of the table data.",
- "type": "string"
-}Output schema / properties / rowsAdded value: +{
+ "description": "Number of data rows (excluding the header).",
+ "type": "integer"
+}Output schema / properties / textAdded value: +{
+ "description": "The converted table as text in to_format.",
+ "type": "string"
+}Output schema / properties / to_formatRemoved value: -{
- "description": "The format the table data was converted to.",
- "type": "string"
-}Output schema / requiredPrevious value: -[
- "converted_data",
- "from_format",
- "to_format"
-]New value: +[
+ "text",
+ "rows",
+ "columns"
+]split_column16 fields changedInput schema / properties / column / descriptionPrevious value: -"The column for this request."New value: +"Column to use: the exact header name (case-sensitive), or a 0-based column index as digits, e.g. \"price\" or \"2\"."Input schema / properties / column / minLengthAdded value: +1Input schema / properties / data / descriptionPrevious value: -"The data for this request."New value: +"The whole table as text, first row = header. CSV/TSV text (quoted cells allowed), or a JSON array of flat objects, e.g. \"name,age\\nAsha,30\"."Input schema / properties / data / minLengthAdded value: +1Input schema / properties / delimiter / descriptionPrevious value: -"The delimiter for this request."New value: +"Literal text to split on, e.g. \" \", \"-\" or \"|\"."Input schema / properties / delimiter / minLengthAdded value: +1Input schema / properties / format / descriptionPrevious value: -"The format for this request."New value: +"Format of 'data' and of the returned table: csv, tsv or json. Default csv."Input schema / properties / format / enumAdded value: +[
+ "csv",
+ "tsv",
+ "json"
+]Input schema / properties / new_names / descriptionPrevious value: -"List of new names values."New value: +"Header names for the new columns; count must equal the maximum number of parts. Default <column>_1, <column>_2, ..."Output schema / properties / dataRemoved value: -{
- "description": "The modified data string with the column split into new columns.",
- "type": "string"
-}Output schema / properties / errorsRemoved value: -{
- "description": "An array of error messages, if any, encountered during the split operation.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / new_columnsRemoved value: -{
- "description": "An array of new column names created from the split operation.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / properties / partsAdded value: +{
+ "description": "Number of new columns the split produced.",
+ "type": "integer"
+}Output schema / properties / statusRemoved value: -{
- "description": "The status of the operation, indicating whether it was successful or if there were any errors.",
- "type": "string"
-}Output schema / properties / textAdded value: +{
+ "description": "The resulting table as text in the input format.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "data",
- "new_columns",
- "status"
-]New value: +[
+ "text",
+ "parts"
+]clean_table5 fields changedInput schema / properties / data / descriptionAdded value: +"The data for this request."Input schema / properties / dedupe / descriptionAdded value: +"Set true to enable dedupe; false otherwise."Input schema / properties / drop_empty_rows / descriptionAdded value: +"Set true to enable drop empty rows; false otherwise."Input schema / properties / format / descriptionAdded value: +"The format for this request."Input schema / properties / trim / descriptionAdded value: +"Set true to enable trim; false otherwise."column_stats4 fields changedInput schema / properties / column / descriptionAdded value: +"The column for this request."Input schema / properties / data / descriptionAdded value: +"The data for this request."Input schema / properties / format / descriptionAdded value: +"The format for this request."Input schema / properties / op / descriptionAdded value: +"The op for this request."convert_table3 fields changedInput schema / properties / data / descriptionAdded value: +"The data for this request."Input schema / properties / from_format / descriptionAdded value: +"The from format for this request."Input schema / properties / to_format / descriptionAdded value: +"The to format for this request."split_column5 fields changedInput schema / properties / column / descriptionAdded value: +"The column for this request."Input schema / properties / data / descriptionAdded value: +"The data for this request."Input schema / properties / delimiter / descriptionAdded value: +"The delimiter for this request."Input schema / properties / format / descriptionAdded value: +"The format for this request."Input schema / properties / new_names / descriptionAdded value: +"List of new names values."clean_table1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "cleaned_data": {
+ "description": "The cleaned table string with trimmed cells, empty rows dropped, and duplicate rows removed.",
+ "type": "string"
+ },
+ "rows_dropped": {
+ "description": "The number of empty rows that were dropped from the table.",
+ "type": "integer"
+ },
+ "rows_duplicated": {
+ "description": "The number of duplicate rows that were removed from the table.",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "cleaned_data"
+ ],
+ "type": "object"
+}column_stats1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "avg": {
+ "description": "The average of the values in the specified column.",
+ "type": "number"
+ },
+ "count": {
+ "description": "The number of values in the specified column.",
+ "type": "integer"
+ },
+ "distinct": {
+ "description": "The number of distinct values in the specified column.",
+ "type": "integer"
+ },
+ "max": {
+ "description": "The maximum value in the specified column.",
+ "type": "number"
+ },
+ "min": {
+ "description": "The minimum value in the specified column.",
+ "type": "number"
+ },
+ "sum": {
+ "description": "The sum of the values in the specified column.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "sum",
+ "avg",
+ "min",
+ "max",
+ "count",
+ "distinct"
+ ],
+ "type": "object"
+}convert_table1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "converted_data": {
+ "description": "The table data converted to the specified format.",
+ "type": "string"
+ },
+ "from_format": {
+ "description": "The original format of the table data.",
+ "type": "string"
+ },
+ "to_format": {
+ "description": "The format the table data was converted to.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "converted_data",
+ "from_format",
+ "to_format"
+ ],
+ "type": "object"
+}split_column1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "data": {
+ "description": "The modified data string with the column split into new columns.",
+ "type": "string"
+ },
+ "errors": {
+ "description": "An array of error messages, if any, encountered during the split operation.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "new_columns": {
+ "description": "An array of new column names created from the split operation.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "description": "The status of the operation, indicating whether it was successful or if there were any errors.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "data",
+ "new_columns",
+ "status"
+ ],
+ "type": "object"
+}clean_tablecolumn_statsconvert_tablesplit_columnDedupe, flatten and clean messy JSON rows (emails, phones, URLs, HTML) in one call, as JSON or CSV.
Clean, dedupe, join and reconcile CSV/Excel files. Runs on Apify, pay per use.
Extract every table from PDFs and scans to Excel, CSV and JSON.
Ask questions about a CSV in plain English and get answers, charts and cleaned data back.
Add one secure layer between your agents and this server.