Skip to main content
Glama

clean_dataset

Apply cleaning operations such as removing duplicates, filling nulls, or renaming columns to a dataset and write the cleaned data to a new file.

Instructions

Apply cleaning operations to a dataset and write a new file.

NEVER modifies the original file. Always writes to output_path.

⚠️ Writing a dataset requires authorization. This tool refuses to write
unless authorized=True (confirm with the user first) or the env var
METIS_ALLOW_DATA_WRITE=1 is set. This mirrors the Claude Code write-gate so
a rebuild can't bypass it via MCP.

Supported operations:
  - "drop_duplicates"                    — remove exact duplicate rows
  - "drop_columns:[col1:col2:...]"       — remove specified columns
  - "fill_na:[col:value]"                — fill nulls in col with value
  - "rename_column:[old_name:new_name]"  — rename a column
  - "strip_whitespace"                   — strip leading/trailing spaces from all string columns
  - "standardize_dates:[col:format]"     — parse col as date (format: 'auto' or strftime)
  - "drop_na_rows:[col]"                 — drop rows where col is null
  - "drop_na_rows_any"                   — drop rows with ANY null value

Args:
    path:         Absolute local path to the source dataset.
    operations:   List of operation strings (see above).
    output_path:  Where to write the cleaned file. If empty, appends '_cleaned'
                  before the extension (e.g. data.csv → data_cleaned.csv).

Returns JSON with: output_path, original_shape, cleaned_shape, row_delta,
col_delta, operations_applied, operations_skipped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
operationsYes
output_pathNo
authorizedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is non-destructive ('NEVER modifies the original file'), describes the write authorization gate, lists all supported operations with syntax, and specifies the return JSON fields. This level of detail fully informs the agent of the tool's behavior.

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

Conciseness4/5

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

The description is well-structured, front-loaded with the key purpose, uses bullet points for readability, and adds necessary detail without excessive verbosity. The only minor issue is some redundancy (e.g., 'NEVER modifies the original file. Always writes to output_path' could be merged), but overall it is efficient and clear.

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?

Given the tool's complexity (4 parameters, 8 operation types, authorization requirement, no annotations) and the presence of an output schema, the description covers everything needed: purpose, behavior, parameter specifics, authorization, default output, and return format. It leaves no critical gaps for an agent to infer.

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

Parameters5/5

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

Schema coverage is 0%, so the description must add all semantic meaning. It does so comprehensively: 'path' is described as 'Absolute local path', 'operations' as 'List of operation strings (see above)' with examples, 'output_path' with default behavior ('If empty, appends _cleaned before extension'), and 'authorized' as a boolean gate. This fully compensates for the lack of schema descriptions and makes parameter usage clear.

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 starts with a clear, specific verb+resource statement: 'Apply cleaning operations to a dataset and write a new file.' It immediately clarifies it never modifies the original file, which distinguishes it from tools that might modify in-place. The extensive list of supported operations further defines the scope and differentiates it from other data-related sibling tools like 'profile_dataset' or 'suggest_cleaning'.

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?

The description explains when to use the tool (to clean a dataset and write output) and crucially notes the authorization requirement ('refuses to write unless authorized=True or env variable set'). It provides a comprehensive list of operations and their syntax. However, it does not explicitly contrast with alternatives like 'suggest_cleaning' (which suggests operations vs. applying them), leaving some ambiguity for the agent about which to use in a given scenario.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SVerITG/Metis'

If you have feedback or need assistance with the MCP directory API, please join our Discord server