MCP field guide / Filesystem
// mcp field guide · devops
The official reference server that gives an agent sandboxed read/write access to your files. Most of what it does is harmless reads — but a handful of tools can overwrite your work with no backup. Notably, it has no delete tool; the real risk is overwrite, not deletion. Here's the sourced breakdown.
GUARD FIT · READ SURFACE (~10 tools)
PASS-THROUGHThe read-only majority (readOnlyHint: true) has no side effect. A guard should classify these low-risk and not add friction.
GUARD FIT · WRITE / EDIT / MOVE
STRONGThe tools the server itself flags destructiveHint: true act on your real files. An impact diff + approval before an overwrite is where a guard earns its keep.
Overall fit: MODERATE — strong precisely for its small destructive surface, near-zero value on the read majority.
@modelcontextprotocol/server-filesystem is one of the actively-maintained reference servers of the Model Context Protocol project (it is not archived — it's listed among the current reference servers, latest npm 2026.7.10).13 It gives an MCP client sandboxed access to the local filesystem, restricted to one or more directories you allow at launch. It refuses any path outside them, and every tool sets openWorldHint: false — no network reach. Within the sandbox it can read, list, search, inspect metadata, create, write, edit, and move files.12
Grouped by each tool's own annotations in the source (readOnlyHint / destructiveHint).2
| Tool | Risk | What it does |
|---|---|---|
| read_text_file | read-only | Read a file's contents as text (optional head/tail limits). |
| read_media_file | read-only | Read a file as base64 with its MIME type. |
| read_multiple_files | read-only | Read several files in one call. |
| list_directory | read-only | List a directory's contents. |
| list_directory_with_sizes | read-only | List with file sizes. |
| directory_tree | read-only | Recursive JSON tree of a directory. |
| search_files | read-only | Recursively find files matching patterns. |
| get_file_info | read-only | Detailed file/directory metadata. |
| list_allowed_directories | read-only | List directories the server may touch. |
| create_directory | mutating | Create a directory (idempotent; cleanly compensable by removing it). |
| write_file | destructive | Create a new file or overwrite an existing one's entire contents. README warns to "exercise caution." |
| edit_file | destructive | Selective in-place edits via pattern matching — rewrites the file on disk. |
| move_file | destructive | Move/rename; can clobber an existing destination. |
The precise risk (worth getting right): there is no delete/remove tool — no delete_file, unlink, or rmdir. So "it can delete your files" is inaccurate. The destructive surface is overwrite (write_file), in-place edit (edit_file), and clobbering move (move_file). Because the server keeps no backups, overwriting existing content is the irreversible case.
Local coding agent. Read a project (read_multiple_files, directory_tree, search_files), then refactor with edit_file/write_file.
Notes / docs assistant. Point it at a folder to search, summarize, and write new drafts back.
Log triage. Read-only-in-practice access to a logs directory; search_files + read_text_file (tail) to find and summarize, no writes.
Don't gate the reads. About ten of the tools are read-only; gating them is pure friction with no protective value. A good guard classifies them low-risk and passes them straight through (ChronoMCP's cascade does exactly this via readOnlyHint).
Do gate write / edit / move. These act on the user's real files, and this is where an impact diff + approval matters. The honest reversibility picture:
| Action | Reversible? |
|---|---|
| create_directory | compensable — remove the created dir |
| write_file creating a new file | compensable — delete the new file |
| move_file | compensable — move it back |
| write_file overwriting existing content | irreversible* — prior bytes are gone |
| edit_file (overwritten regions) | irreversible* |
* The honest asterisk: an overwrite is only "compensable" if the guard snapshots the original bytes before the call — the server won't do it for you. Absent a pre-image, overwrite and clobber are irreversible, and a guard should say so in the diff rather than promise an "undo." That's the compensation-is-not-undo line, applied to files.
ChronoMCP passes read-only calls through and gates write_file/edit_file/move_file on a human — with an honest diff of what can't be undone.
readOnlyHint/destructiveHint): index.ts@modelcontextprotocol/server-filesystem (v2026.7.10); reference-server status per modelcontextprotocol.io/examples: npmjs.com/package/@modelcontextprotocol/server-filesystemProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with these projects. Capabilities reflect sources current as of Aug 2026 and can change — check the source links for the latest.