Most filesystem servers hand back bytes; this one parses PDF and Office formats on the way in and renders them on the way out, which removes the conversion step that usually ends the task. The same server also carries execute_shell, and the guard around it is worth understanding before you enable it: commands are matched against the `--approved-commands` list, and paths written inside a command are validated against the allowed directories rather than trusted. Scope is dynamic by design — what the model can reach is whatever has been approved at startup or registered since.
A filesystem server that treats office documents as first-class files, adds glob and regex search, bulk file operations and a guarded shell. Everything runs locally against a list of allowed directories.
- Reading in full, head, tail or range mode across text and documents including PDF, DOCX, PPTX, XLSX, ODT, ODP and ODS, with PDF extraction carrying font, colour and layout metadata (read_file, read_multiple_files).
- Writing text, PDF and DOCX, where HTML in the payload becomes headings, bold, italic, colours, tables and lists in the output (write_file, write_multiple_files).
- Editing with exact, flexible or fuzzy matching, over one file or many, with a diff preview before the change lands (edit_file).
- Search that separates locating from reading: glob patterns over paths, and regex over contents with case-insensitivity, context lines and file-type filters, returning line numbers (glob_files, grep_files).
- Bulk move, copy, rename and delete with conflict strategies, run concurrently and capped at 100 entries per operation (file_operations, delete_files).
- Directory scope that widens during a conversation rather than only at startup, with the pre-approved list injected into the tool descriptions so the model does not re-register what it already has (register_directory, list_allowed_directories).
- The ordinary filesystem verbs: recursive directory creation, listings as a simple list, a detailed view with sizes and timestamps, a tree or structured JSON, atomic moves and renames that refuse to overwrite, and full metadata for a path (make_directory, list_directory, move_file, get_file_info).
- An image handed to the model as if the user had uploaded it, so diagrams and screenshots can be described or read (attach_image).
- Shell execution with a timeout and a working directory, capturing stdout, stderr, exit codes and signals, with paths inside the command validated against the allowed directories just like a file operation (execute_shell).
Node.js 14 or higher; launch with `npx -y @n0zer0d4y/vulcan-file-ops` over stdio. Directory access is the real setup: pass `--approved-folders` with absolute paths at startup, let the client supply workspace roots over the MCP Roots protocol, or have the model call register_directory during the conversation. Three more flags shape what it can do — `--approved-commands` whitelists shell commands, `--ignored-folders` keeps directories such as node_modules out of listings, and `--enabled-tools` or `--enabled-tool-categories` narrows the surface to what you actually want exposed. No account and no key.
One command — npx -y @n0zer0d4y/vulcan-file-ops