well-016-datacleanup
Server Details
CSV cleanup: dates, emails, phones, dedupe. x402 $0.005 USDC, Base. As is, no warranty.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 1 tool
With only a single tool, there is no possibility of tool-to-tool confusion; an agent can only select data-cleanup, and its purpose (CSV normalization plus duplicate handling) is spelled out clearly.
There is only one name, so no inconsistency is possible, and 'data-cleanup' is readable kebab-case. It deviates from the verb_noun convention (no verb, arguably an object noun), so it is not a perfect pattern match.
One tool is on the thin side, but the server's stated scope is a single deterministic cleanup operation that bundles trimming, normalization, dedupe, and reporting into one call. Splitting it would add little value, so the minimal surface is defensible.
The tool covers the core CSV-cleaning lifecycle (whitespace, case, dates, emails, phones, exact/fuzzy dedupe) plus a report, which is solid for the domain. Gaps remain around configurable output formats, column selection, and custom rule extension, which an agent must work around.
Available Tools
1 tooldata-cleanupARead-onlyIdempotentInspect
Clean a CSV ($0.005 USDC): give an https url or inline csv (max 1 MB / 20k rows). Trims whitespace, optional case rules, dates to ISO 8601, lowercases emails, normalizes phone digits, merges or flags exact + fuzzy duplicate rows on key_columns. Returns cleaned CSV text + JSON report (rows in/out, dupes, columns changed). Deterministic, no AI. As is, no warranty. Nothing stored. As is, no warranty. Nothing stored.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | No | Inline CSV text instead of url (max 1 MB). | |
| url | No | Public https URL of a CSV (max 1 MB). | |
| fuzzy | No | Also match near-duplicates (case/punctuation/accents, small typos). Default true. | |
| dedupe | No | merge (default) keeps first row and fills its blanks; flag adds _duplicate_of_row; none. | |
| case_rules | No | Map column -> lower | upper | title. | |
| date_order | No | Order for ambiguous numeric dates (default mdy). | |
| has_header | No | First row is a header (default true). | |
| max_groups | No | Max duplicate groups listed in report (default 50, max 500). | |
| key_columns | No | Columns used to detect duplicates (default all). | |
| date_columns | No | Columns to convert to ISO 8601 (default auto). | |
| phone_format | No | digits (default) or e164. | |
| email_columns | No | Email columns to lowercase (default auto). | |
| phone_columns | No | Phone columns (default auto by header name). | |
| fuzzy_threshold | No | Similarity 0.5-1 for typo matches (default 0.92; 1 = normalized-equal only). | |
| trim_whitespace | No | Trim and collapse whitespace in every cell (default true). | |
| default_country_code | No | Country code for e164 when missing (default 1). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/idempotent/openWorld): it discloses cost, that the operation is deterministic with no AI, that nothing is stored, that output is a cleaned CSV plus a JSON report, and that there is no warranty. Cost and data-retention behavior are exactly the kind of context annotations cannot carry.
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 action, price, and input options before the transformation list, which is good ordering. However, the clause 'As is, no warranty. Nothing stored.' is duplicated verbatim, wasting space in an otherwise dense description.
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 16-parameter tool with no output schema, the description covers the return payload (cleaned CSV text + JSON report with rows in/out, dupes, columns changed), input limits, cost, and data handling. Combined with 100% schema coverage and annotations, an agent has everything needed to invoke 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 all 16 parameters are already documented with defaults and enums. The description restates the pipeline features (fuzzy dedupe on key_columns, merge vs flag) but adds no syntax or semantics the schema lacks, 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 ('Clean a CSV') and immediately enumerates the concrete transformations performed (trim, case rules, ISO 8601 dates, email lowercasing, phone normalization, dedupe). No siblings exist, so no differentiation is needed, and the scope is unmistakable.
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?
Specifies how to supply input ('give an https url or inline csv') and the hard limits (max 1 MB / 20k rows), plus pricing ($0.005 USDC), which tells an agent when this call is viable. It does not state any when-not conditions or alternatives, but with no sibling tools that omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
data-cleanup
Related MCP Connectors
https CSV to headers and rows. x402 $0.005 USDC, Base. As is, no warranty.
Normalize messy CSV into your schema; ambiguous values return as exceptions. $0.02 USDC via x402.
Free list of Rainmaker tools + paid need-to-tool router. x402 $0.005 USDC, Base. As is, no warranty.
Real-time RFC 5322 email verification, SPF/DMARC DNS audits & B2B leads (x402 Base USDC).
Related MCP Servers
- AlicenseAqualityBmaintenanceI built this local stdio MCP adapter to discover, preview, and purchase live agent data APIs, including vendor risk, company intelligence, transaction preflight, and EVM reads. Free discovery and previews require no wallet. Optional paid calls settle in Base USDC through x402 v2; auto-pay is disabled by default.276 npmMIT
- AlicenseNot gradedqualityCmaintenanceReal-time email verification API with syntax, MX, disposable detection, role-based flags, quality score 0-100. Built for agent outreach pipelines with pay-per-call via x402 (USDC on Base L2) -- no API key, no signup, no rate-limit wall.MIT

hyperd-mcpofficial
AlicenseAqualityDmaintenancePre-trade DeFi intelligence for AI agents. 20 paid x402 endpoints, USDC on Base.2390 npm1MIT- FlicenseNot gradedqualityDmaintenanceManages LinkedIn prospecting CSV files with deduplication and search, reducing LLM token usage by offloading file operations.-
Glama MCP Gateway
Add one secure layer between your agents and this server.