# File Organizer MCP Server

Version 5.0.0 | MCP protocol 2026-07-28 (stateless) | Node.js 20+

[![npm version](https://img.shields.io/badge/npm-v5.0.0-blue.svg)](https://www.npmjs.com/package/file-organizer-mcp)
[![npm downloads](https://img.shields.io/npm/dm/file-organizer-mcp.svg)](https://www.npmjs.com/package/file-organizer-mcp)
[![License](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
[![Tests](https://img.shields.io/badge/tests-835%20passing-success.svg)](tests/)

A Model Context Protocol (MCP) server that organizes files. It gives a Claude-style assistant a single atomic operation to categorize, sort, dedupe, and rename files, instead of making it chain dozens of primitive `read`, `write`, and `rename` calls.

- [Why](#why)
- [Quick start](#quick-start)
- [Features](#features)
- [Tools](#tools)
- [File categories](#file-categories)
- [Example workflows](#example-workflows)
- [Security](#security-configuration)
- [Troubleshooting](#troubleshooting)
- [Architecture](#architecture)
- [Documentation](#documentation)

---

## Why

A filesystem MCP server built only on `read`, `write`, `make`, and `delete` forces an assistant to plan every move and rename as a separate step. Each step costs tokens, and more steps means more chances to get the path wrong.

File Organizer MCP replaces those chains with one call:

| Primitive approach                     | File Organizer MCP                                |
| -------------------------------------- | ------------------------------------------------- |
| Many `read` / `write` / `rename` calls | `organize_files()` runs the whole move atomically |
| Dozens of reasoning steps              | One reasoning step                                |
| High token use                         | Minimal token use                                 |
| Easy to corrupt on partial failure     | Rollback-safe operations                          |

---

## Quick start

### One-command setup

```bash
npx file-organizer-mcp --setup
```

The wizard detects installed AI clients (Claude Desktop, Cursor, Windsurf, Cline, and others), configures them, and walks you through folder selection and preferences.

### Requirements

Node.js 20 or newer.

### After setup

You can ask the assistant things like:

- "Organize my Downloads folder"
- "Find duplicate files in my Documents"
- "Show me my largest files"
- "Which categories take up the most space in my Downloads?"

### Install methods

| Method | Command                             | Use case                    |
| ------ | ----------------------------------- | --------------------------- |
| npx    | `npx file-organizer-mcp --setup`    | Occasional use or a trial   |
| Global | `npm install -g file-organizer-mcp` | Regular use, faster startup |

---

## Features

- Categorization into 12 or more file types.
- Cron-based automatic organization and directory watch mode.
- Duplicate detection by SHA-256 content hash.
- Disk usage per category: which file types hold the space, in bytes and as a share.
- Metadata extraction: EXIF for photos, ID3 for audio.
- Smart organization that picks the right strategy per file type.
- Date sorting into `YYYY/MM` folders from EXIF date taken (photos) or file mtime, reporting which date each file used.
- Dry-run preview, atomic moves, and rollback.
- Plan validation before you organize: name collisions, occupied destinations, cross-device moves, and files the sensitive-file gate blocks.
- Path traversal protection, TOCTOU mitigation.
- Windows, macOS, and Linux.

---

## Tools

### Core tools

- `file_organizer_scan_directory` - List a directory with detailed file info. `directory` is required; `include_subdirs` toggles recursion.
- `file_organizer_read_file` - Read a file through the validated path pipeline. `path` is required; `encoding` is utf-8, base64, or binary.
- `file_organizer_batch_rename` - Rename many files by pattern, regex, or numbering. Checks the whole plan for name collisions first: if a real run would put two files on one name, or overwrite a name a different file already holds, the batch is rejected before anything moves and the conflicts come back as structured data.
- `file_organizer_undo_last_operation` - Reverse the most recent organization.
- `file_organizer_quarantine_files` - Set flagged files aside for review, reversibly. See below.
- `file_organizer_restore_quarantine` - Put quarantined files back where they came from.
- `file_organizer_search_history` - Filter the history by path glob (`path_glob`), date range (`from`/`to`), or operation type. Every filter is optional and they combine, so a long history stays queryable instead of one flat list.
- `file_organizer_export_report` - Write a health report for a directory in one call: totals, space per category, duplicate groups, largest files. Pass `output_path` to leave a file behind, or leave it out and nothing is written. See below.

### Full tool list (37 tools)
<!-- BEGIN GENERATED TOOL LIST -->
- `file_organizer_analyze_duplicates`
- `file_organizer_batch_read_files`
- `file_organizer_batch_rename`
- `file_organizer_categorize_by_type`
- `file_organizer_delete_duplicates`
- `file_organizer_disk_usage_by_category`
- `file_organizer_doctor`
- `file_organizer_export_config`
- `file_organizer_export_report`
- `file_organizer_find_broken_symlinks`
- `file_organizer_find_duplicate_files`
- `file_organizer_find_empty_directories`
- `file_organizer_find_largest_files`
- `file_organizer_find_old_files`
- `file_organizer_get_categories`
- `file_organizer_inspect_metadata`
- `file_organizer_list_files`
- `file_organizer_organize_by_date`
- `file_organizer_organize_by_project`
- `file_organizer_organize_files`
- `file_organizer_organize_music`
- `file_organizer_organize_photos`
- `file_organizer_preview_delete_duplicates`
- `file_organizer_preview_organization`
- `file_organizer_quarantine_files`
- `file_organizer_read_file`
- `file_organizer_restore_quarantine`
- `file_organizer_scan_directory`
- `file_organizer_search_history`
- `file_organizer_sensitive_scan`
- `file_organizer_set_custom_rules`
- `file_organizer_smart_suggest`
- `file_organizer_system_organize`
- `file_organizer_undo_last_operation`
- `file_organizer_validate_organization_plan`
- `file_organizer_verify_integrity`
- `file_organizer_view_history`
<!-- END GENERATED TOOL LIST -->

For parameters and return shapes, see [API.md](API.md).

### Quarantine: set files aside without losing them

Scanning flags a suspicious file. Deleting it is not reversible. Quarantine is
the middle option: the file is **moved** into a hidden quarantine directory
inside the directory you named, and it stays readable on disk.

```text
file_organizer_quarantine_files({
  directory: "~/Downloads",
  files: ["~/Downloads/invoice.exe"],
  reason: "flags as executable content",
})
```

Reversibility is the whole point, so it comes back two ways:

- `file_organizer_undo_last_operation` — the existing undo path. Quarantine
  writes the same rollback manifest the organizer writes, so undo is the same
  call you already use.
- `file_organizer_restore_quarantine` — reads that manifest and puts every file
  back at the exact path it was taken from. The restore writes a manifest of
  its own, so the restore is reversible too.

What to know before you move something:

- **Dry run by default.** A bare call lists what *would* be quarantined and
  moves nothing. Pass `dry_run: false` to apply it.
- **Nothing is deleted.** No file is removed from disk by quarantine. Only its
  location changes.
- **The quarantine directory is derived, not hardcoded.** By default it is
  `.file-organizer-quarantine` inside the `directory` you passed, which means it
  inherits that directory's access grant. Set `quarantine_dir` to move it
  elsewhere — it goes through the same path validation as any other directory,
  so it cannot be pointed outside your allowed directories.
- **Same names do not collide.** Two files called `notes.txt` become
  `notes.txt` and `notes_1.txt`. Neither overwrites the other, and a restore
  puts each back at its own original path.
- **One batch at a time.** Every listed file must live inside `directory`. If any
  path is outside it, nothing moves.
- **Paths in the result are absolute**, like `organize_files`. They are
  canonicalised, so they differ in spelling by platform — Windows expands 8.3
  short names (`RUNNER~1` becomes `runneradmin`) and macOS rewrites `/var` to
  `/private/var`. Compare basenames, or normalise both sides, instead of
  comparing raw path strings.

### Scheduled organization (separate process)

The stdio MCP server stays stateless — cron-based watching runs as its own
process:

```bash
file-organizer-watch add ~/Downloads "0 10 * * *"   # daily at 10am
file-organizer-watch list
file-organizer-watch                                # start the daemon
```

Watches are stored in the shared user config, so `add`/`remove` work even
while the daemon is running (restart it to pick up changes).

#### Single pass from an OS timer

`once` runs one organization pass and exits, holding no watcher, no timer, and
no open handle. That is the mode cron, launchd, a systemd timer, or Task
Scheduler drives:

```bash
file-organizer-watch once ~/Downloads              # dry run, writes nothing
file-organizer-watch once ~/Downloads --apply      # move, then exit
file-organizer-watch once . --apply --recursive --json
```

##### Exit codes

| Code | Meaning                                                    |
| ---- | ---------------------------------------------------------- |
| `0`  | Pass finished, moved nothing — empty dir or dry run        |
| `1`  | Failed: bad flags, refused path, per-file errors, or abort |
| `2`  | Pass finished clean and moved at least one file            |

`1` wins over `2` even when files moved, so a partial pass never looks like
success.

##### `--json`

`--json` prints exactly one JSON object on stdout and nothing else. Logs,
usage, and failure text go to stderr, so stdout stays parseable whether the
run succeeded or not.

```json
{
  "ok": true,
  "exitCode": 2,
  "directory": "/home/you/Downloads",
  "dryRun": false,
  "scanned": 12,
  "planned": 8,
  "moved": 8,
  "skipped": 4,
  "historyLogged": true,
  "aborted": false,
  "errors": []
}
```

Every key is always present, including on failure — a refused path reports the
same shape with `ok` false, `exitCode` 1, and the reason in `errors`. `ok` is
true for exit codes 0 and 2. `historyLogged: false` on an applied pass means
no history row was written for the moves: nothing names that pass in history
and there is no id to undo it by, though the manifest may still be on disk.
When it is `true`, the row carries the rollback manifest id whenever the pass
managed to write one, so `file_organizer_undo_last_operation` can reverse the
pass file by file. A pass whose manifest write failed has a row with no id:
the pass is in history, but it cannot be undone by handle.

On a pass that ran, `directory` is the **resolved** path, not the argument
verbatim — the same convention every tool uses (`file_organizer_organize_files`
reports the directory its path validator approved). It is the path the gate
checked and the pass scanned, so symlinks are already followed and `~` is
expanded. The two forms differ on macOS (`/var/folders/...` →
`/private/var/folders/...`) and on Windows (an 8.3 short name like `RUNNER~1`
expands to the long name), so a caller must not string-compare it against what
it passed in.

The one exception is a failure that never reached a scan — a path the gate
refused, or a thrown error. There is no approved path to report, so `directory`
carries the original argument exactly as typed. Key your reports on `exitCode`
and `errors`, not on `directory`.

When scripting a pipeline, keep the CLI's exit code — without `pipefail` the
pipeline reports `jq`'s status, and a pass that moved files and then failed
would look like success:

```bash
set -o pipefail

# alert only when files moved AND the pass was clean.
# .ok rejects a partial pass that moved files but then failed.
file-organizer-watch once ~/Downloads --apply --json \
  | jq -e '.ok and (.moved > 0)' >/dev/null && echo "organized"
```

For a read-only sweep — scan plus `preview_organization` on a timer, no moves —
see [examples/scheduling](examples/scheduling/README.md). It has ready-to-copy
recipes for three surfaces:

| Surface        | Trigger                     | Config                                                                                           |
| -------------- | --------------------------- | ------------------------------------------------------------------------------------------------ |
| Claude Desktop | headless `claude -p`        | [claude-desktop.config.json](examples/scheduling/claude-desktop.config.json)                     |
| Codex          | `codex exec`                | [codex.config.toml](examples/scheduling/codex.config.toml)                                       |
| cron / systemd | `file-organizer-watch once` | [crontab.example](examples/scheduling/crontab.example), [systemd/](examples/scheduling/systemd/) |

---

## File categories

| Category    | Typical extensions                           |
| ----------- | -------------------------------------------- |
| Executables | `.exe`, `.msi`, `.bat`, `.sh`                |
| Videos      | `.mp4`, `.avi`, `.mkv`, `.mov`               |
| Documents   | `.pdf`, `.doc`, `.docx`, `.txt`, `.md`       |
| Images      | `.jpg`, `.jpeg`, `.png`, `.gif`, `.webp`     |
| Audio       | `.mp3`, `.wav`, `.flac`, `.m4a`              |
| Archives    | `.zip`, `.rar`, `.7z`, `.tar.gz`             |
| Code        | `.py`, `.js`, `.ts`, `.java`, `.go`, `.json` |

---

## Example workflows

### Clean up a Downloads folder

1. Scan the folder and review the file distribution and space use.
2. Identify duplicates and stale files.
3. Preview the moves and conflicts.
4. Confirm, then organize into category folders.

Result: a sorted folder, duplicates flagged, and reclaimed space.

### Organize a project

The assistant scans the project, splits files into Code, Assets, and Docs, keeps the `src/` tree intact, and moves loose config files, readmes, and screenshots into their proper folders.

### Find and handle duplicates

The assistant hashes files, groups duplicates, scores each copy by location, name quality, and age, and recommends which to keep and which to delete. It reports the wasted space. You decide whether to delete.

### Discover large files

Point it at a folder and it lists the largest files by size, flags old backups you can archive, and notes any large duplicates.

### Organize music

It reads ID3 tags and rebuilds the folder as `Artist / Album / Title.mp3`.

```
Before:
Downloads/
  song1.mp3
  track02.mp3
  music_file.mp3

After:
Music/
  Coldplay/
    A Rush of Blood to the Head/
      Clocks.mp3
      The Scientist.mp3
  Radiohead/
    OK Computer/
      Paranoid Android.mp3
      Karma Police.mp3
```

### Organize photos

It reads the capture date from EXIF and sorts photos into date-based folders. The default `date_format` is `YYYY/MM`; the example below uses `YYYY/MM/DD`.

```
Before:
Pictures/
  IMG_001.jpg
  photo123.png
  DSC_4567.raw

After:
Pictures/
  2023/
    12/
      25/
        IMG_001.jpg
      31/
        photo123.png
  2024/
    01/
      15/
        DSC_4567.raw
```

### Security-screen a folder

`file_organizer_sensitive_scan` reads the metadata block of every JPEG and TIFF in a
folder and scores each one 0-100 for the risk of sharing it. It flags EXIF GPS
coordinates and altitude, GPS fix timestamps, owner and artist names, camera and
lens serial numbers, camera or computer make and model, copyright lines,
capture/editing software, and free-text notes. Each score arrives with the
individual findings and the weight each one added, so the number is a sum of
stated causes:

```json
{
  "name": "IMG_4471.jpg",
  "risk_score": 70,
  "risk_level": "high",
  "reasons": [
    { "kind": "gps_coordinates", "weight": 40, "exif_tags": ["GPSLatitude", "GPSLongitude"], "value": "51.5073, -0.1277" },
    { "kind": "owner_name", "weight": 30, "exif_tags": ["OwnerName"], "value": "Jane Q Public" }
  ]
}
```

**A score of 0 is not a clearance to share the file.** The detection is
heuristic and the tool never modifies anything: it reports what it recognizes,
and it does not look at PDF annotations, XMP, IPTC, embedded thumbnails, file
names, or what is visible in the picture. Files outside JPEG and TIFF are listed
under `skipped` with a reason. Treat the scan output itself as sensitive, since
it echoes the values it found.

### Set up automatic organization

Register a directory with a cron schedule:

```json
{
  "directory": "/Users/john/Downloads",
  "schedule": "0 9 * * *",
  "rules": {
    "auto_organize": true,
    "min_file_age_minutes": 5
  }
}
```

The server organizes the folder on that schedule. Add more watches for other directories.

---

## Security configuration

Access is restricted to a whitelist of user directories by default. System directories stay blocked.

### Allowed by default

The server enables these locations if they exist on the machine:

| Platform | Allowed directories                                                                                                                          |
| -------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Windows  | Desktop, Documents, Downloads, Pictures, Videos, Music, Projects, Workspace, workspace, Development, Code, OneDrive (if set)                 |
| macOS    | Desktop, Documents, Downloads, Pictures, Videos, Music, Projects, Workspace, workspace, Development, Code, Movies, iCloud Drive, /Volumes    |
| Linux    | Desktop, Documents, Downloads, Pictures, Videos, Music, Projects, Workspace, workspace, Development, Code, `~/dev`, /mnt, /media, /run/media |

Only directories that exist and are not symlinks are returned.

### Always blocked

These paths stay blocked even if you add them to the config:

- Windows: `C:\Windows`, Program Files, AppData, `$Recycle.Bin`
- macOS: `/System`, `/Library`, `/Applications`, `/private`, `/usr`
- Linux: `/etc`, `/usr`, `/var`, `/root`, `/sys`, `/proc`
- Everywhere: `node_modules`, `.git`, `.vscode`, `.idea`, `dist`, `build`

### Custom configuration

Edit the user config file:

- Windows: `%APPDATA%\file-organizer-mcp\config.json`
- macOS: `$HOME/Library/Application Support/file-organizer-mcp/config.json`
- Linux: `$HOME/.config/file-organizer-mcp/config.json`

Add paths to `customAllowedDirectories`:

```json
{
  "customAllowedDirectories": [
    "C:\\Users\\Name\\My Special Folder",
    "D:\\Backups"
  ]
}
```

You can paste a folder path straight from your file explorer's address bar.

### External drives and network mounts

Paths outside your home directory are blocked unless you opt in. To allow an external volume such as `/Volumes/My Drive` on macOS or `/media/user/usb` on Linux, set `allowExternalVolumes` to true:

```json
{
  "allowExternalVolumes": true,
  "customAllowedDirectories": [
    "/Volumes/MyExternalDrive",
    "/Volumes/Photography Backup"
  ]
}
```

Windows drive letters like `D:\` work without this flag.

Restart the client after editing the config.

### Moving your config to another machine

`file_organizer_export_config` bundles the whole user config — allowed
directories, custom rules, conflict strategy, watch entries, auto-organize and
history settings — into one JSON document you can copy to a laptop or a fresh
install:

```typescript
// writes the bundle; refuses to overwrite an existing file
file_organizer_export_config({ output_path: "~/fom-config-bundle.json" });
// omit output_path to get the bundle in the reply without writing one
```

Rules, strategies and schedules mean the same thing anywhere. Directory paths
do not: they are absolute paths of the machine that exported them, so they will
not exist on the target and they do describe your directory layout. The reply
always says so:

- **absolute mode** (the default) exports the paths exactly as configured and
  lists every field to edit by hand in `requires_editing`.
- **rebased mode** takes a `rebase_root` — normally the home directory — and
  rewrites each path under it as `~/relative`, which follows the target
  machine's home. A path outside that root cannot be rebased; it is exported
  unchanged and named in `non_portable_paths`.

```typescript
file_organizer_export_config({
  rebase_root: "~",
  response_format: "json",
});
// → requires_editing: [], directories exported as ["~/Documents", "~/Downloads"]
```

Copy the bundle to the other machine, apply the edits it names, and merge its
`config` into that machine's `config.json`. The tool never writes the config
file itself, and the bundle file is the only thing it writes.

### Conflict strategy

```json
{
  "conflictStrategy": "rename"
}
```

- `rename` (default) - Append a suffix to the new file, for example `file (1).txt`.
- `skip` - Keep the existing file and skip the new one.
- `overwrite` - Replace the existing file, after writing a backup.

### Legacy auto-organize schedule

For a simple hourly, daily, or weekly schedule:

```json
{
  "autoOrganize": {
    "enabled": true,
    "schedule": "daily"
  }
}
```

For anything more granular, run `file-organizer-watch add <directory> "<cron>"`.

### Defenses

| Attack type         | Protection                                     |
| ------------------- | ---------------------------------------------- |
| Unauthorized access | Whitelist plus blacklist enforcement           |
| Path traversal      | validatePathBase, see ARCHITECTURE.md         |
| Symlink attacks     | Real path resolution                           |
| DoS                 | Resource limits on file count, depth, and size |

---

## Troubleshooting

### The MCP server does not appear

1. Check the config file path is correct.
2. Confirm Node.js 20 or newer: `node --version`.
3. Fully restart the client.
4. Check the path in the client config file.

### Permission errors

- Windows: run the client as Administrator.
- macOS/Linux: check folder permissions with `ls -la`.
- Confirm the target directory is writable.

### Files are not moving

1. Make sure `dry_run` is not enabled.
2. Close programs that may be locking the files.
3. Check for sufficient disk space.
4. Read the operation summary for error messages.

### Custom rules are missing after a restart

`file_organizer_set_custom_rules` saves the accepted rules to `config.json` in your
OS config directory and every later request reads them from there. Three things
to know:

- The call replaces the whole saved set, so it is not a per-rule merge.
- Rules with an unknown category or a rejected pattern are skipped; the reply
  says how many were applied.
- If the write itself fails — read-only config directory, missing permissions —
  the call returns an error instead of a success message, and the server log
  holds the cause. Nothing is persisted in that case.

---

## Architecture

The server is stateless: each JSON-RPC request gets a fresh context (`config`, history logger) routed through an explicit tool registry into pure service modules under `src/core/`. The pipeline is `scan → categorize → plan → move`, every path passes `validatePathBase` before any `fs` call, and all side effects are file-backed (history, rollback manifests), so nothing survives a restart except what you can undo.

Scheduled organization runs as a separate process (`file-organizer-watch`) so the stdio server stays request/response.

See [ARCHITECTURE.md](ARCHITECTURE.md) for the diagram and design notes.

---

## Documentation

- [API.md](API.md) - Complete tool reference
- [ARCHITECTURE.md](ARCHITECTURE.md) - Design and architecture
- [examples/scheduling](examples/scheduling/README.md) - Scan + preview sweep recipes for Claude Desktop, Codex, cron, and systemd
- [CONTRIBUTING.md](CONTRIBUTING.md) - Contribution guidelines
- [MIGRATION.md](MIGRATION.md) - v2 to v3 upgrade guide
- [CHANGELOG.md](CHANGELOG.md) - Version history
- [SECURITY.md](SECURITY.md) - Security model and reporting

---

## Contributing

Read [CONTRIBUTING.md](CONTRIBUTING.md), then clone and build:

```bash
git clone https://github.com/kridaydave/File-Organizer-MCP.git
cd File-Organizer-MCP
npm install
npm run build
npm test
```

### Adding a tool: one file, one line

1. Create `src/tools/my-tool.ts` exporting a `ToolDefinition` (name, Zod input schema, annotations, formats) and its handler.
2. Add an import and one `reg()` entry in `src/mcp/registry.ts`.

That's it. The registry is the single source of truth: the server registers from it, routing is pure, and no other file changes. Schemas shared across tools live in `src/schemas/` (`common`, `scan`, `organize`, `system`). If your tool takes a path, it goes through `validateStrictPath` before touching `fs`, and errors go through `sanitizeErrorMessage`. See [ARCHITECTURE.md](ARCHITECTURE.md) for the contract details.

Report bugs and feature requests on [GitHub Issues](https://github.com/kridaydave/File-Organizer-MCP/issues). For a security vulnerability, email technocratix902@gmail.com.

## License

MIT. See [LICENSE](LICENSE).