# 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 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, or any pass you name by the manifest id it returned and `file_organizer_view_history` lists. Pass `cascade: true` to walk back through every pass made after that one, newest first. An older pass whose files a newer pass also touched is refused unless you ask for the cascade. - `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 (42 tools) - `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_list_watches` - `file_organizer_organize_by_date` - `file_organizer_organize_by_project` - `file_organizer_organize_files` - `file_organizer_organize_music` - `file_organizer_organize_photos` - `file_organizer_organizer_digest` - `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_unwatch_directory` - `file_organizer_validate_organization_plan` - `file_organizer_verify_integrity` - `file_organizer_view_history` - `file_organizer_watch_directory` - `file_organizer_watch_status` 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 reverses a quarantine. writes the same rollback manifest the organizer writes, so undo is the same call you already use. - `file_organizer_restore_quarantine`. It 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). **An OS timer is the primary path.** Point cron, a systemd timer, or Task Scheduler at `once` (below) and the machine's own scheduler owns the schedule: it survives reboots, it is visible in `crontab -l`, and it needs no process of ours running. ```bash # crontab -e: daily at 10am, labelled scheduled so history can filter on it 0 10 * * * file-organizer-watch once ~/Downloads --apply --source scheduled ``` The daemon is the fallback for a machine with no timer to point at. Both run the same pass over the same watch config, so a watched directory behaves the same way either way: same history row, same rollback manifest id, and the same per-directory limits from `watch add` (the age filter and the file cap). The daemon adds one thing a cron line does not have, which is catchup: on startup it reads `scheduler-state.json` and runs a schedule that was missed while the machine was off. #### 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. These rules follow the directory, not the process that started the sweep: a cron line running `once --source scheduled` over this folder gets the same age filter and file cap the built-in daemon would apply. A pass you run by hand with no `--source` is never filtered. --- ## 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 ""`. ### Notification after a pass A scheduled pass that actually moved files can run one command, so you find out without watching the log: ```json { "notify": { "command": "notify-send \"Organized\" \"$FOM_NOTIFY_MOVED files\"", "throttleMinutes": 60 } } ``` The command is tokenized into argv and spawned without a shell. Quotes group arguments and `|`, `>` and `&&` are literal; write `sh -c "..."` when you do want a pipeline. It gets `FOM_NOTIFY_DIRECTORY` and `FOM_NOTIFY_MOVED` in its environment. Nothing runs on a dry run, or on a pass that moved nothing. The throttle is per directory and the first notification for a directory always goes out, so a failed command or a full disk cannot silence you for good. A command that fails is logged and never fails the pass. ### Rollback retention Rollback manifests expire. The default window is 30 days, and expired manifests are deleted the next time anything reads the rollback directory. ```json { "rollback": { "retentionDays": 30 } } ``` `0` keeps every manifest forever. A negative value clamps to `0`, so it keeps everything rather than expiring everything. Only manifests this install wrote and can still verify are eligible; an unverified or corrupt file stays visible instead of being deleted. If a rollback is in flight when a read happens, the prune skips that pass and tries again later. ### 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).