Skip to main content
Glama

CSV cleaning: normalise, deduplicate, and tidy a CSV

submit_csv_clean
Idempotent

Clean a CSV and return the cleaned file plus a record of every change. Trims cells, makes duplicate and empty column names unique, drops blank and duplicate rows, and pads or truncates ragged rows. Choose this when you want the CSV itself tidied and a change log: cells trimmed, column names made unique, blank and duplicate rows removed, ragged rows padded or truncated. Do not choose this when you only need the problems listed (use csv-preflight), or when deciding which duplicate to keep needs a business rule: this keeps the first occurrence. Example requests: Clean this CSV: trim the fields, drop the blank lines and remove duplicate rows. | Normalise this export before I load it, and tell me what you changed. | Fix the duplicate column names and ragged rows in this CSV.

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": {
      "inputs": "<inputs>",
      "authorized_by": "<authorized_by>"
    },
    "name": "submit_csv_clean"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputsYes
quote_idNoThe quote_id returned by POST /v1/jobs. Required to authorize a priced capability; the service rejects a priced job that does not name the quote it issued.
authorized_byYesIdentifier of the human or agent authorizing this job.
accepted_priceNoThe amount accepted, exactly as quoted (for example "5.00" or 5). Checked against the stored quote, so a price that moved between quote and authorize is refused rather than silently absorbed. Optional, but sent to make the acceptance explicit.

Output Schema

NameRequiredDescriptionDefault
quoteNo
stateYes
job_idYes
artifactsNo
access_tokenNoPer-job credential. Present it as the X-Job-Token header to read the job or list it. Keep it; it is the only credential for this job.
verificationNoIndependent verification. verification.ok = false means the job failed, not a partial success.
capability_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare non-readonly, idempotent, non-destructive, closed-world, and the description adds real behavioral detail on top: determinism (first occurrence wins), what the response contains (file plus change log), and the ragged-row policy. It omits the priced-job/authorization behavior (quote_id, accepted_price) that makes this a metered capability, which is a meaningful gap for an agent judging cost and failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and routing, but the second sentence and the 'Choose this when' clause repeat the same transform list nearly verbatim ('cells trimmed, column names made unique, blank and duplicate rows removed, ragged rows padded or truncated'). Three example requests for a single-input tool is more real estate than the feature set warrants.

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?

Output schema exists, so return values need no prose, and annotations cover the safety profile; the description covers transforms, edge-case policy, and sibling routing. The main omission is that this is a priced/authorized capability, which an agent must infer from the schema's quote_id and accepted_price fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the schema already documents most parameters, and per the coverage rule that sets a baseline of 3. The description adds nothing about the four parameters – notably no mention of input size/delimiter tolerance (only 'CSV') or the quote/price authorization fields – so it neither compensates nor detracts.

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 ('Clean a CSV') plus the exact transforms applied (trim cells, unique column names, drop blank/duplicate rows, pad or truncate ragged rows) and the paired return ('cleaned file plus a record of every change'). This is clearly distinguishable from sibling submit_csv_preflight, which only reports problems.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('Choose this when you want the CSV itself tidied and a change log'), explicit when-not ('Do not choose this when you only need the problems listed (use csv-preflight)'), and an exclusion condition with the built-in policy ('when deciding which duplicate to keep needs a business rule: this keeps the first occurrence'). An agent can route correctly without opening any schema.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources