Summary
The file that was too large to read stops being a dead end.
Chunking is the default rather than a flag you remember to set, so a long file, a deep directory and a wide search all come back in pieces you can keep pulling. The edit side is built the same way round: preview_only, expected_replacements and per-edit backups mean a replacement that would hit the wrong text can be seen before it lands.
What it is
A filesystem server built around chunking: 25 tools for reading, writing, searching, editing, moving, compressing and syncing, where large results resume from a continuation token rather than arriving at once.
What you get
- Reads that auto-chunk, accept a line range or byte offset, and resume with a continuation_token — including several files in one call
- Writes with an append mode and directory creation, plus a large-file path that adds streaming, retry, backup and write verification
- Search by filename or file content, and a ripgrep-style code search returning line numbers and context lines
- Exact block edits guarded by expected_replacements and preview_only, a risk-checking variant with a safety level, and multi-block edits applied in one pass
- Directory work: paginated listings with sorting and patterns, a tree to a chosen max_depth, disk usage, and large files found by min_size
- File operations with a safety net — copy, move, delete with backup_before_delete, and batch operations with dry_run
- Archives and synchronisation: compress with exclude patterns and a compression level, extract, and sync two directories with dry_run
Requirements
Npx on your PATH, and paths inside the directories the server allows — fast_list_allowed_directories returns that set. No account, no key.
Setup effort
One command — npx -y fast-filesystem-mcp