MCP Filesystem server

The server holds no credentials, reads no environment variables, starts no other programs and makes no network calls, so there is no token to steal or forward. It does, however, run with the full file permissions of whoever launched it (or as root inside the shipped Docker image), and the only thing narrowing that is the allowed-directories check, which is scored under tool scoping. If that check failed, the server could read and write anything the user can, including SSH keys, cloud credential files and shell startup files.

As a tool server, this project cannot ask the user for approval itself; it gives the host the information to do so. Reading tools and writing tools are separate, and every tool carries accurate hints: all ten read tools are marked read-only and the write, edit and move tools are marked destructive. The edit tool offers a dry-run preview, but overwriting a whole file and moving files have no preview, and the server has no read-only mode of its own. Overwrites are immediate and keep no backup, so a wrongly approved write cannot be undone by the server.

This is the server's strongest area. Every tool takes a path and every path goes through one validation function that resolves symlinks with realpath, checks containment against the allowed directories with a separator-aware comparison, rejects null bytes, and for new files walks each existing parent component checking it stays inside. Writes avoid following pre-existing symlinks by using exclusive creation and atomic rename. The tools are narrow (no shell, no network), but all of them, including write, edit and move, are always on, there is no read-only switch, and nothing bounds file sizes or result counts. Path containment is not a complete boundary.

The server never runs code: there is no shell, no process spawning and no dynamic evaluation anywhere in its source. It can write files that some other program might later execute, but that execution happens outside this server and is not counted here.

The server's job is to hand file contents to the model, so any file in the allowed directories can carry a prompt injection. Contents are returned as plain text with no marker that they are untrusted and no source path attached (except in the multi-file read), so the host gets nothing it could act on. The server has no network access of its own, so it cannot itself send data out, but a hijacked model can use it to overwrite or rearrange files without any check from the server, and paired with any egress-capable tool on the same host the full leak-plus-damage chain is open.

Nothing the model does can change how the server behaves later. There is no memory, cache or database, no settings file is read from the allowed directories, and configuration comes only from command-line arguments and the client's roots list.

The server loads no third-party code at runtime: no plugins, no dynamic imports, no package installs and no other MCP servers. How the host installs this server (the README's npx -y line fetches the latest version) is the host's supply-chain concern and is not scored here.

The server holds no keys or tokens and reads no environment variables, so there is nothing of its own to leak, and its stderr log lines contain directory paths and error messages but never file contents. It has no telemetry. But it does nothing to protect secrets that sit in the allowed directories: a .env file, private key or credentials file is returned to the model verbatim, with no denylist or redaction.

The server keeps no record of what it did. Tool calls, their arguments and results are not logged anywhere; the only output is a handful of startup and roots-change messages on stderr. Reconstructing an incident depends entirely on whatever the host application chose to log.

The server puts no limits on its own work. Whole files are read into memory regardless of size, the multi-file read takes any number of paths at once, and the directory tree and search tools walk the entire directory with no depth or result limit. The only bounds are the optional head and tail line counts the caller may pass. Requests cannot be cancelled mid-way, though stopping the server process ends everything because it starts no background work or child processes.