File Organizer MCP Server

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

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
• Quick start
• Features
• Tools
• File categories
• Example workflows
• Security
• Troubleshooting
• Architecture
• 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

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)

• 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

For parameters and return shapes, see 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.

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:

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:

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.

{
  "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:

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. It has ready-to-copy recipes for three surfaces:

Surface	Trigger	Config
Claude Desktop	headless claude -p	claude-desktop.config.json
Codex	codex exec	codex.config.toml
cron / systemd	file-organizer-watch once	crontab.example, 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:

{
  "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:

{
  "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:

{
  "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:

{
  "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:

// 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.

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

{
  "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:

{
  "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 for the diagram and design notes.

---

Documentation

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

---

Contributing

Read CONTRIBUTING.md, then clone and build:

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 for the contract details.

Report bugs and feature requests on GitHub Issues. For a security vulnerability, email technocratix902@gmail.com.

License

MIT. See LICENSE.