Inspect, filter, sort and edit CSV text with four free tools. No account or API key required.
Scored across 4 tools
Each tool has a clearly distinct operation: inspect, filter, sort, and edit. There is little risk of confusing one tool with another because their names and descriptions align on separate CSV actions.
All tools follow a consistent snake_case verb_noun pattern: edit_csv_cells, filter_csv_rows, inspect_csv, sort_csv_rows. The slight shortening in inspect_csv is still predictable and readable.
Four tools is a well-scoped set for basic CSV inspection and manipulation. Each tool earns its place without obvious redundancy or unnecessary surface area.
The set covers inspection, filtering, sorting, and cell editing, but lacks row deletion, column creation/removal, and CSV creation from scratch. These are notable gaps for a general CSV file toolset, though some workflows can be partially worked around.
Apply up to 1,000 explicit edits to existing cells only. Zero-based row indices include the header. Duplicate coordinates apply in input order. Return complete CSV with literal string values; never evaluate formulas.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | Yes | Complete UTF-8 CSV text, up to 256 KiB. All cells remain strings; formulas are never evaluated. | |
| edits | Yes | ||
| delimiter | No | Explicit delimiter; no delimiter inference. | , |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/idempotent/non-destructive already declared, the description adds substantial new context: zero-based indexing that includes the header, duplicate coordinates applied in input order, and that values stay literal strings with formulas never evaluated. These are exactly the execution semantics an agent cannot infer from annotations.
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?
Four compact sentences, front-loaded with the core action and capacity limit, then indexing rules, then duplicate handling and return contract. 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?
No output schema exists, and the description compensates by specifying the return ('complete CSV with literal string values'), plus delimiter behavior is covered by the schema. Minor omission: no statement of what happens on out-of-range row/column or invalid CSV.
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 67% and the 'row' property has no schema description, so the description's 'zero-based row indices include the header' is the only source for that critical detail; duplicate-coordinate ordering is also unique to the description. The delimiter parameter is left entirely to the schema, which does document it with 'no delimiter inference'.
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 ('Apply ... edits to existing cells') and bounds the operation ('existing cells only', up to 1,000). It does not name any sibling, but filter_csv_rows/sort_csv_rows/inspect_csv are clearly distinct operations, so ambiguity risk is low.
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?
The phrase 'existing cells only' implicitly scopes the tool against row/column insertion, but there is no explicit when-to-use or when-not-to-use guidance, no mention of alternatives, and no stated error behavior for out-of-range coordinates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keep data records whose explicit zero-based column equals an exact string. Header defaults to preserved. Reject missing target columns; preserve empty and ragged records otherwise.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | Yes | Complete UTF-8 CSV text, up to 256 KiB. All cells remain strings; formulas are never evaluated. | |
| value | Yes | ||
| column | Yes | Zero-based column index. Every data record must contain this column. | |
| delimiter | No | Explicit delimiter; no delimiter inference. | , |
| hasHeader | No | Preserve the first record as a header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real behavioral detail: exact-match semantics, rejection of missing target columns, and preservation of empty and ragged records. It stops short of describing the returned row order or error surface, keeping it at 4.
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 tight sentences, front-loaded with the core operation, then the header default, then failure/preservation behavior. No filler or restated name.
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 read-only filter with no output schema and full annotation coverage, the description covers matching semantics and edge cases adequately. It omits anything about output row ordering or the return shape, which is a minor gap.
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 80%, so the schema already documents csv, column, and delimiter. The description reinforces 'explicit zero-based column' and 'header defaults to preserved' but adds little beyond the schema, and never mentions value or delimiter choice; 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 plus resource: 'keep data records whose explicit zero-based column equals an exact string' — precisely what filtering means here. It never names inspect_csv or edit_csv_cells to differentiate, so it falls short of a 5 despite being unambiguous.
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?
Usage is only implied by the operation itself; there is no explicit 'use this when you want to subset rows, use inspect_csv to preview or sort_csv_rows to reorder.' The edge-case rules (reject missing columns, preserve empty/ragged records) hint at the contract but not at when-to-call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return record, maximum column and cell counts with up to 20 preview records. Preserve ragged and empty records; never infer types or a delimiter.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | Yes | Complete UTF-8 CSV text, up to 256 KiB. All cells remain strings; formulas are never evaluated. | |
| delimiter | No | Explicit delimiter; no delimiter inference. | , |
| previewRows | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is prefilled. The description still adds real behavioral context beyond them: ragged and empty records are preserved rather than normalized, and no type or delimiter inference occurs. It doesn't say how counts are computed or how the preview is truncated (head vs. sample), which keeps it below 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?
Two sentences, both front-loaded with the highest-value facts (what is returned, then the fidelity guarantees). No filler or restatement of the title.
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?
No output schema exists, so the description must sketch the return shape — it does (counts plus up to 20 preview records). For a 3-parameter read tool with full annotations and a well-documented schema this is close to sufficient; only the exact meaning of 'maximum cell counts' and preview ordering remain unstated.
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 67% and the schema itself documents csv (256 KiB limit, all cells strings, formulas not evaluated) and delimiter (explicit, no inference). The description echoes the delimiter/no-inference contract and the 20-record preview cap, but adds little on the csv parameter and nothing on previewRows=0 behavior. Baseline 3 is appropriate when the schema carries most of the detail.
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 set: return record/column/cell counts plus preview records. That clearly separates a read-only inspection from the mutating siblings (edit_csv_cells, filter_csv_rows, sort_csv_rows). It stops short of naming a sibling explicitly, so it lands at 4 rather than 5.
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?
The purpose implies usage — profile a CSV before editing/filtering/sorting it — but the description never says when to prefer this tool over its siblings or what conditions rule it out. Guidance is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stably sort data records by an explicit zero-based column using literal code-unit string order, asc or desc. Header defaults to preserved. No numeric, date or locale inference. Reject missing target columns.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | Yes | Complete UTF-8 CSV text, up to 256 KiB. All cells remain strings; formulas are never evaluated. | |
| column | Yes | Zero-based column index. Every data record must contain this column. | |
| delimiter | No | Explicit delimiter; no delimiter inference. | , |
| direction | No | asc | |
| hasHeader | No | Preserve the first record as a header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds real behavior: stable sort, code-unit ordering rather than numeric/date/locale collation, header preservation by default, and that missing target columns are rejected rather than padded. It does not say what the returned value looks like (sorted CSV text) or how quoting/embedded newlines are handled.
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?
Four short sentences, front-loaded with the core operation, no filler. The telegraphic fragments ('Header defaults to preserved.', 'Reject missing target columns.') are efficient though slightly clipped in register.
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?
This is a transformation tool with no output schema, so the description should state that it returns the sorted CSV text and how the header row behaves in the output. Ordering semantics and error behavior are covered, but the result shape is left entirely implicit.
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 80%, so the schema already documents all five parameters well. The description reinforces only `column` (zero-based), `direction` (asc/desc) and `hasHeader` (preserved) and gives no new information about `delimiter` or the size constraint on `csv`; 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 ('Stably sort data records by an explicit zero-based column') plus the exact comparison semantics (literal code-unit string order) and the direction axis. This is unambiguously distinct from the sibling operations edit/filter/inspect without needing to name them.
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?
Usage is implied by the operation itself (sort a CSV by a column), and 'No numeric, date or locale inference' hints at a boundary, but there is no explicit when-to-use/when-not guidance or comparison to filter_csv_rows or edit_csv_cells. The agent must infer that sorting is the alternative to filtering from the verb alone.
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.
edit_csv_cellsfilter_csv_rowsinspect_csvsort_csv_rowsConvert and clean tables: CSV, JSON, dedupe, stats. Free.
Validate and clean CSV before import. Find duplicates, missing values and invalid dates with row-level reports. Apply only the cleanup you request; files are not retained. Run view_csv_demo free without a key. Custom CSV: EUR 9 for 100 operations, valid 90 days, no subscription. Setup: https://check.orvel.dev/docs/
Paste-your-data analytics: CSV profiling, A/B tests, correlation, growth. 4 of 7 free.
70 tools: JSON repair, CSV, hashes, cron, dates, units, validators. 25 free calls.
Add one secure layer between your agents and this server.
