FilesMCP servermeasured 19 Aug 2026

Filesystem

Filesystem is Anthropic's reference MCP server for giving a model scoped read and write access to local directories. You pass it a list of allowed paths on the command line, and it exposes 14 tools for reading, writing, editing, moving, listing and searching inside those paths. It refuses anything outside them, which is the whole design.

Anthropic (reference) · official · protocol 2025-06-18 · v0.2.0 · measured by Keyoor

BootBOOTS ✓We started it and initialize came back in 9.0s.

Tools14tools/list payload 12,973 bytes

Context tax~3,243estimated tokens for the whole tools/list, chars/4 estimate

Resources / prompts— / —counts returned by resources/list and prompts/list

Measured19 Aug 2026one run of the harness, clean environment, no credentials · how we test

How we started it

npx -y @modelcontextprotocol/server-filesystem /home/mcpprobe/probe-dir

Verdict

Use it. It is the closest thing MCP has to a standard library: the sandboxing story is explicit, every one of its 14 tools has a real description, and when we booted it the tools/list payload came to 12,973 bytes, roughly 3,243 tokens by the chars/4 estimate. The honest cost is that this is above the median server we measured in this batch, and you are paying it on every single turn even if the agent only ever calls read_text_file. If your agent already has shell access, you are buying a permission boundary, not new capability.

Use it if

You want an agent editing files in one project directory and nothing else, enforced by the server rather than by a prompt

You are running an MCP client with no built-in file tools and need read, write, edit and search in a single install

You need the allowed-path list auditable in the config file, so a reviewer can see the blast radius without reading code

You want edit_file's line-based patching instead of making the model rewrite whole files

Skip it if

Your client already ships native file tools; you would be paying about 3,243 tokens for a second copy of them

You need access to paths that change per task, since the allowed directories are fixed at launch unless the client supports MCP Roots

You are on a tight context budget and only need one operation, in which case a small purpose-built server costs less

You expect the sandbox to protect you from a hostile model: it constrains paths, not intent, and write_file inside an allowed directory is still a write

You want remote or containerised file access, which this does not do

The bill for your context window

Tool	Est. tokens	Described?	Required params
read_media_file	~316	yes (234 chars)	1
read_text_file	~285	yes (457 chars)	1
edit_file	~268	yes (185 chars)	2
search_files	~255	yes (424 chars)	2
read_multiple_files	~247	yes (324 chars)	1
list_directory_with_sizes	~237	yes (323 chars)	1
directory_tree	~231	yes (360 chars)	1
move_file	~225	yes (325 chars)	2

For 14 tools, 3,243 estimated tokens is fair but not cheap, and the weight is spread rather than concentrated: the largest single entry, read_media_file, is about 316 tokens, and nothing dominates. That flatness is because the descriptions are genuinely written, several running past four hundred characters to explain path rules and edit semantics. You are paying for documentation quality. If you never touch images, dropping read_media_file at the client is the one obvious trim; beyond that there is no fat to cut, only tools to remove.

Setup reality

There are no environment variables. We started it with npx and a single directory argument, and that argument list is the security policy: everything you name is writable, everything else returns an error. First boot took 8,995 ms on our box, almost all of it npm fetching the package, and stderr carried a deprecation warning about an old glob dependency before the server line appeared. It also logged that our client does not support MCP Roots, so it fell back to the directories from the command line. Clients that do support Roots can negotiate the paths at runtime instead. It speaks stdio and protocol 2025-06-18.

Questions people ask

Can the filesystem MCP server escape the directories you give it?

Not through the tools themselves. Every path is checked against the allowed list before the operation runs, and list_allowed_directories exists so the model can see its own limits. Symlinks pointing outside are rejected too. It does not stop a process you launch by other means.

Why did it take almost nine seconds to start?

That was npx downloading the package on a cold cache, not the server. Once installed, startup is the Node process only. If nine seconds in your client's boot path matters, install the package globally and point the command at the binary.

What are MCP Roots and do I need them?

Roots let the client hand the server its working directories at connection time instead of on the command line. Ours did not support them, so the server used its arguments and said so on stderr. You do not need Roots, but with them one config entry can follow whatever project is open.

Is it worth the context cost next to a shell tool?

If you already have shell access, no new capability arrives with this. What arrives is a boundary the model cannot argue its way past and a set of file operations with structured errors. Teams that want an audit trail on scope usually decide that is worth the tokens.

Other files servers we started

Server	Vendor	Boots	Context tax
Excel	community (negokaz)	✓	~1,406 tokens
Google Drive (archived)	Anthropic (archived)	✗	~0 tokens

How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.

← All measured MCP servers