Kobel vs. MCP Filesystem Server

The official server is the most common answer to “give the AI access to my files”. It is open source, free, and does exactly what it promises. It only knows one question: allowed or not allowed.

Last verified: 2026-08-23

In short

@modelcontextprotocol/server-filesystem has exactly one dial: the list of allowed directories. It is passed as an argument at startup or set by the client through the roots protocol. Everything on that list is open to every tool the server offers — including write_file, whose own description reads: “Create new file or overwrite existing (exercise caution with this)”.

Kobel replaces that one dial with five levels per folder and puts a log underneath. That is the whole difference — and in practice it is the difference between “the AI may enter my working directory” and “the AI may write proposals, read accounting, and not even see the archive”.

One dial versus five levels

The official server does not distinguish between folders it may change and folders it should only look at. It distinguishes between folders on the list and everything else. From the README, verbatim: “All filesystem operations are restricted to allowed directories” and “Server requires at least ONE allowed directory to operate”.

There is an annotation called readOnlyHint on the reading tools. The README says what it is for: so clients can “distinguish read-only tools from write-capable tools”. It is a hint to the interface, not a lock. The decision whether to write is ultimately taken by the client — the very program whose behaviour you were trying to constrain.

A detail that surprises people

If the client supports the roots protocol, the roots it reports replace the directories set on the command line entirely — the README says “completely replace”. There is an open issue in the project because users lost their carefully chosen directories that way. So if you drew your boundary in a JSON file, be aware the client can redraw it.

Feature comparison

	MCP Filesystem Server	Kobel
What it is	Reference MCP server for file access, MIT licence	Desktop app acting as a local MCP gateway that enforces the permissions
Boundary	List of allowed directories	Five levels per folder
Read-only in the server	No	Yes (yellow)
Write with backup	No	Yes (teal)
Read original, write copies	No	Yes (orange)
Make a folder invisible	Only by leaving it off the list	Yes (red), explicitly blocked
Activity log	No	Yes, timestamped, CSV/JSON export
Setup	Edit a JSON file, add an `npx` invocation; on Windows via `cmd /c`	Drag a folder in, pick a colour
Change the folder list without a restart	Via client roots, otherwise config and restart	Yes, in the interface
Tools	13, of which `write_file`, `edit_file`, `move_file`, `create_directory` write	File, app and account tools under the same permission rule
Apps and accounts too	No, files only	Yes, via app proxy and connectors
Open source	Yes, MIT	No
Cost	Free	Free tier; €49 once or €3.90/month
Platforms	Anywhere Node or Docker runs	Windows and macOS

What the two CVEs say about the design

In the summer of 2025 two vulnerabilities in the filesystem server were disclosed, both since fixed:

CVE-2025-53109 (CVSS 8.4) — symlinks inside an allowed directory could give access to files outside it.
CVE-2025-53110 (CVSS 7.3) — a directory name that merely started with the name of an allowed directory was treated as allowed.

Both are patched, and the fact that they were reported, documented and fixed speaks well of the project. What is interesting is the shared pattern: in both cases a path comparison was the entire security boundary. If that one line is wrong, there is no second boundary and no record to notice it by afterwards. That is precisely why a permission layer with graded rights and a log has a different security profile from a path list — not because it is free of bugs, but because one bug does not immediately mean everything.

What the official server does better

It is open source, free, and runs anywhere Node or Docker runs — including Linux, where Kobel does not exist. It is the reference implementation everything else is measured against, its code is auditable, and edit_file has a preview mode (dryRun) that shows what a change would do before it happens. If you are at home in a terminal, work in a single project folder and need no log, you need nothing more.

When each one fits

MCP Filesystem Server, if …

A single project folder is enough
You edit JSON configurations anyway
You are on Linux
Open source is a requirement
Nobody will later need to prove what happened

Kobel, if …

Different folders need different rights
Changes should be backed up automatically
You need a log the AI cannot reach
The person setting the rules will not open a config file
Apps and accounts should follow the same rules

Kobel's five permission levels

Every folder, app and account carries exactly one of these five levels. You set it by dragging a folder in and picking a colour — no configuration file.

GreenRead and write. The AI may open files and save changes directly.
TealWrite with an automatic backup. A copy is made before every change, so a bad edit can always be undone.
OrangeRead the original, write only to copies. The AI can work with the data but cannot alter the source file.
YellowRead only. Look, don't touch.
RedBlocked. The resource is invisible to the AI.

Keep reading

Sources

Try it with one folder

Install Kobel, drag in a single folder, set it to read-only, connect your AI. Two minutes. Free tier, no account needed.

Download Kobel See the features

Kobel is available for both desktop platforms:Microsoft Store Windows 10/11 Mac App Store macOS

Frequently asked questions

Can the MCP filesystem server make a folder read-only?

Not within the server itself. The server takes a list of allowed directories — via command line arguments or via the client's roots protocol — and all of its tools then apply to those directories equally, the reading ones and the writing ones. No read-only mode is described in the README, and the current npm build carries no command line options at all beyond the directory list. Read-only is only reachable outside the server, by running it in a container with a bind mount and the ro option.

What does readOnlyHint mean?

It is an annotation on the tools so a client can distinguish read-only tools from write-capable ones. It is a hint to the interface, not a lock in the server. Relying on it means relying on the client to honour it.

Does the MCP filesystem server keep a log?

No. The published build has no log file and no structured logging; messages go to standard error. If you later want to know which file was changed and when, you will not find it there.

Is the official server insecure?

It is the reference implementation, open source under MIT, and both known vulnerabilities were fixed long ago: CVE-2025-53109 (escaping allowed directories via symlinks, CVSS 8.4) and CVE-2025-53110 (prefix collision on directory names, CVSS 7.3). The lesson is not a warning about the project but a statement about the design: a path comparison is the entire security boundary. If it is wrong, there is no second one.

Does Kobel replace the MCP filesystem server?

For access to local folders, yes — Kobel brings its own file tools and enforces the permissions itself, so an additional filesystem server is not needed. For anything else, no: Kobel is not a replacement for the MCP ecosystem, and if you need a particular other MCP server you keep running it.

Why do I need more than allowed directories?

Because in practice not every allowed directory deserves the same treatment. The proposals folder should be editable, the accounting folder read-only, the archive untouched. With a single list of allowed directories you have to pick one of those answers and apply it to all three.