Skip to main content
Glama

clean_data

Destructive

Clean a messy spreadsheet or JSON export into typed, deduplicated records with a log of each change. Use it when a spreadsheet or export needs cleaning or deduplicating before analysis or import. It finds the header row, works out each column's type from the values (ids incl. barcodes/ISBN/IBAN check digits, emails, phones, dates, times, durations, money, percents, quantities with units, ZIP and postal codes, states, countries, US street addresses, coordinates, URLs, names, booleans), keeps leading zeros, reads European decimals, repairs broken encodings and merges duplicate records. It flags what deserves a look without changing it: disposable or role emails, phone numbers that can't exist, failed check digits. Returns rows, changes (row, column, before, after, rule), review (each with a type: invalid, conflict, possible_duplicate (a group of records that look like the same person or company, with a confidence, the evidence and the strongest pairs' likelihoods; never merged), shared_email (records sharing an email whose names, birth dates, ID numbers or Jr./Sr. say different people, kept apart), totals_row or note_row, and the reason), columns (with the evidence for each choice), quality (share of clean cells before and after), clusters (likely typos), a JSON schema, a reusable recipe and stats, whose counts always add up to the input rows. A file holding several tables (stacked, titled, or side by side) is split: the largest is the main result and every other table comes back cleaned under other_tables. Price: $0.50 per 1,000 rows across all tables, minimum $0.01.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "clean_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoPublic http(s) link to a CSV, TSV, XLSX or JSON file, up to 100 MB. Use this or content_base64.
hintsNoForce a column's type, e.g. {"Joined": "date"}. Types: id, email, phone, date, datetime, time, duration, money, percent, number, quantity, zip, postcode, us_state, state, country, address, latitude, longitude, coordinates, url, name, boolean, text.
sheetNoExcel only: the sheet to clean. Default: the first sheet with data.
tableNoWhen the file holds several tables, which one is the main result (1 = first). Default: the largest; the others are in `other_tables`.
recipeNoThe `recipe` from an earlier run. Pass it to clean a new file with the same column types and rules.
filenameNoFile name with extension (e.g. customers.csv). Required with content_base64 so the format is known.
requiredNoColumns a row must have; rows missing one go to the review list.
dedupe_onNoColumns that identify a record; rows matching on them merge into one. Default: the email column, else the whole row.
header_rowNoThe file line holding the column names, if the automatic choice is wrong (1 = first line).
phone_formatNo'national' like (415) 555-0100, or 'e164' like +14155550100.national
phone_regionNoTwo-letter country for phone numbers written without a country code, e.g. US, GB, DE.US
content_base64NoThe file itself, base64-encoded, for small files you hold locally. Use this or url.
fix_email_typosNoCorrect obvious typos in big mail providers (gmial.com -> gmail.com). Every fix is in the change log.
min_duplicate_confidenceNoList look-alike records as possible duplicates from this likelihood (0-1). Default 0.5; 0.9 for only the near-certain ones; 1 means only the surest (99.5%).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, non-idempotent and non-read-only, so the safety profile is covered; the description adds genuinely new behavior: review items are flagged 'without changing' them, possible duplicates are 'never merged', shared_email records are 'kept apart', multi-table files are split with the largest as main result, and pricing is $0.50 per 1,000 rows with a $0.01 minimum. What is missing is any statement about what the destructive hint actually implies (whether the source file or a stored dataset is altered).

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?

The first sentence is a well-placed summary, but the body becomes a dense run-on that packs the type list, every return key, and the billing formula into one paragraph. Much of that enumerates fields an agent only needs after the call, which dilutes the invocation-relevant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of describing returns and does so thoroughly: rows, changes, review types, columns, quality, clusters, schema, recipe, stats, and other_tables, plus a guarantee that stats counts add up to input rows. Combined with 100% schema coverage for inputs and pricing disclosure, nothing material is missing for a 14-parameter tool.

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 description coverage is 100%, so every one of the 14 parameters is already documented with examples and defaults in the schema. The description's return-field prose reinforces how dedupe and duplicate-confidence behave, but it adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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?

The description opens with a specific verb and resource: clean a messy spreadsheet or JSON export into typed, deduplicated records with a per-change log. It enumerates the concrete operations (header detection, type inference, encoding repair, duplicate merge), which no sibling tool (get_job_result, listen_clip, research, transcribe) covers, so an agent can select it 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.

Usage Guidelines4/5

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

It gives a clear trigger condition: 'Use it when a spreadsheet or export needs cleaning or deduplicating before analysis or import.' That is a usable when-to-use rule, but it offers no explicit exclusions, prerequisites, or alternative paths (e.g. when to skip cleaning and read raw), 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.