Validate CSV columns, find duplicates and invalid values, and clean files with explicit rules. Row-level reports, no stored files. Run the fixed free sample without a key. Custom CSV: EUR 9 for 100 operations, valid 90 days, no subscription. Setup: https://import-check-production.up.railway.app/docs/
Scored across 5 tools
clean_csv (transform) and validate_csv (read-only check) are clearly distinct, and get_csv_usage is unique. However, get_csv_example and view_csv_demo both center on a fixed synthetic example, so an agent could reasonably be unsure which to reach for when just exploring.
All five tools use a consistent snake_case verb_noun pattern (clean_csv, get_csv_example, get_csv_usage, validate_csv, view_csv_demo). The convention is predictable and readable throughout.
Five tools are well-scoped for a focused validate-and-clean service. It is slightly lean, with two of the five dedicated to example/demo material, but nothing is excessive.
The surface covers the core lifecycle: validate, clean/transform, plus a schema example, demo, and key/usage check. Minor gaps exist (e.g. no explicit schema-inference or export/persist helper), but agents can work around them via clean_csv's csv_text output.
Apply only requested column renames and transformations, then validate the output against schema. Cleanup column names refer to the original headers; schema names refer to the renamed output. Transformations run in listed order. decimal_comma changes only plain numbers such as 12,50; ambiguous grouping stays unchanged. No records or columns are removed. Returned csv_text is UTF-8-compatible with CRLF record endings. One paid operation includes cleanup and validation. Spreadsheet-safe escaping is opt-in and may make numeric negative cells fail numeric validation; inspect the final report before import.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | ||
| cleanup | Yes | ||
| csv_text | Yes | ||
| delimiter | No | , | |
| request_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: no records or columns are removed, output is UTF-8 with CRLF endings, it is a single paid operation, and spreadsheet_safe may break numeric validation. The 'no columns removed' claim is consistent with destructiveHint=false. It stops short of describing failure behavior (e.g., what happens if validation fails).
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?
Six tight sentences, each carrying distinct information; the core operation is front-loaded in sentence one and the risk caveat is deferred to the end where it belongs. Slightly dense, but no sentence is 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 no output schema, the description usefully characterizes the return (csv_text, UTF-8, CRLF) and notes a final report. It omits error/validation-failure behavior and does not cover two top-level parameters, but for a stateless transform tool the picture is nearly complete.
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?
Top-level schema coverage is 0%, so the description must compensate. It does for the hardest semantics: 'Cleanup column names refer to the original headers; schema names refer to the renamed output' disambiguates the two objects, and the decimal_comma note clarifies that action. It says nothing about the delimiter or request_id parameters, leaving those to the enum/defaults.
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 opening sentence names a specific compound action — apply only the requested column renames/transformations, then validate the output against schema. This distinguishes it from the validate_csv sibling, which only validates. An agent can tell what this tool does and how it differs from its siblings without opening the 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?
The description says transformations run 'in listed order' and that cleanup names refer to original headers while schema names refer to renamed output, which implies correct usage. However, it never states when to prefer this tool over validate_csv or get_csv_usage, nor any prerequisite/exclusion conditions. Usage is implied rather than specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a fixed synthetic CSV and its column schema. Free, no key or quota. Copy the structure, then supply your own CSV to validate_csv.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description earns credit by adding cost/auth context not present in annotations: 'Free, no key or quota', plus the deterministic 'fixed synthetic' nature of the payload.
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 return value, then cost, then the follow-on action. 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?
There is no output schema, and the description does say what comes back (CSV plus column schema). It omits return-format specifics such as delimiter or how the schema is represented, but for a zero-parameter example tool this is largely complete.
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, so there is nothing for the description to disambiguate; baseline is 4. No misleading parameter claims are made.
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: returns a fixed synthetic CSV plus its column schema. It also implicitly distinguishes itself from siblings by pointing at validate_csv as the place to send real data, whereas this tool provides the reference example.
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 a concrete workflow: copy the structure, then supply your own CSV to validate_csv. That names the alternative and the condition for moving on, though it never says when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read remaining operations and expiry for the API key supplied in the Authorization header. Does not consume credit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds the genuinely useful behavioral fact that the call does not consume credit, but says nothing about invalid/missing key behavior or any rate limits.
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 short sentences, front-loaded with the operation and result, followed by a single high-value constraint. 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 parameterless read with no output schema, the description covers the resource read and the auth source. It does reasonably cover returns by naming 'remaining operations and expiry', though it does not describe response formatting.
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?
Zero parameters, so the schema cannot carry semantic load. The description compensates by stating the credential comes from the Authorization header rather than a parameter, which is the key input detail an agent needs.
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 (read) and resource (remaining operations and expiry), and identifies the subject as the API key from the Authorization header. This clearly separates it from the sibling CSV-content tools (clean_csv, validate_csv), though it doesn't explicitly 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 purpose — check quota before spending operations — and the note 'Does not consume credit' hints at when it is safe to call. However, there is no explicit when-to-use or when-not-to-use guidance relative to the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a CSV against your explicit schema; return all issue counts and at most 200 detailed findings. Headers match exactly; required=false permits empty cells, not missing headers. Unique compares raw non-empty strings. Dates use YYYY-MM-DD, decimals use a dot without grouping, booleans use true/false. A valid=false report is a completed paid operation, not a tool failure. No values are changed; use clean_csv for explicit transformations. Validity covers only the supplied rules, not destination-system or business correctness.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | ||
| csv_text | Yes | CSV text including header. UTF-8, at most 1 MB; no file paths or URLs. | |
| delimiter | No | , | |
| request_id | No | Optional 8–128 character retry key. Reuse only for identical arguments; changed data requires a new key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: result truncation cap ('at most 200 detailed findings'), and critically the billing semantics ('a valid=false report is a completed paid operation, not a tool failure'), which prevents an agent from misreading a failed validation as an error. Also states the no-mutation guarantee and the limited scope of the validity verdict.
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?
Dense but front-loaded, with the core purpose first and constraints ordered by importance. Each clause carries information, though the run-on constraint list could be broken up for readability.
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 no output schema, the description still characterizes the return value (issue counts plus capped detailed findings), the error/billing semantics, and the verdict's scope. Nothing an agent needs to call this correctly and interpret the result 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?
Schema coverage is 50%, and the description compensates by specifying value-level semantics the schema omits: exact header matching, required=false permitting empty cells but not missing headers, unique comparing raw non-empty strings, and date/decimal/boolean lexical formats. Delimiter and request_id are left to their schema 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?
States a specific verb+resource ('Check a CSV against your explicit schema') and immediately distinguishes itself from the sibling clean_csv by scope of responsibility. An agent can tell what it does and what it does not do without opening the 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?
Explicitly routes the agent: 'use clean_csv for explicit transformations' and clarifies that this tool changes no values. It also bounds validity to supplied rules rather than destination/business correctness. Missing only explicit negative conditions (e.g. when not to use it at all).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate the fixed example with the current engine. Free and no arguments; demonstrates duplicate, email, amount and date findings. Custom files require validate_csv and paid access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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), so the bar is lower. The description still adds real context beyond them: no arguments required, free of charge, and the specific categories of findings produced (duplicate, email, amount, date). It does not describe output format or pagination, but with no output schema that is a minor gap.
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, each earning its place: what it does, how to call it, and what to use instead for custom files. Front-loaded with the action and constraints.
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-argument, read-only demo tool with no output schema, the description covers purpose, cost, invocation, expected finding categories, and the sibling alternative. Nothing critical is missing, though return shape for the demo findings is unspecified.
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, so the baseline is 4. The description reinforces this with 'no arguments', leaving no ambiguity about how to invoke it.
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: validates a fixed example with the current engine. It explicitly distinguishes itself from the sibling validate_csv by noting that custom files require that tool. An agent can route correctly 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?
Explicitly declares 'free and no arguments' and routes the alternative case ('custom files require validate_csv and paid access'). This gives both the when-to-use condition and the when-to-use-something-else condition with the named alternative.
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_csvget_csv_exampleget_csv_usagevalidate_csvview_csv_demo
Add one secure layer between your agents and this server.