Filesystem MCP

The 82/100 score is carried by the filesystem boundary rather than by feature count. For this category, a server that reads and writes files is only useful if path containment remains dependable under traversal, symlinks and recursive operations.

Modern Filesystem MCP performs that core job well. The score is held below the high-80s by write-loss risk, hidden-file exposure, scope surprises from Roots, cross-platform reliability issues and incomplete migration to MCPVerdict's current 2026-07-28 compatibility criteria.

Why it scores well

• explicit allowed-directory model;
• modern real-path and symlink containment;
• local stdio operation with no third-party MCP host;
• clear tool annotations for read-only, destructive and open-world behavior;
• only 13 tools, keeping definition overhead relatively low;
• edit_file supports dry-run diff previews;
• Docker makes a second OS-level boundary practical.

Why it does not score higher

• dotfiles are not excluded by default;
• write_file overwrites existing files;
• move_file has a recent reproduced destination-overwrite bug on an affected release;
• MCP Roots can replace CLI-provided directories rather than merge with them;
• recursive trees/searches can dump large, irrelevant or sensitive context;
• Windows and schema/client compatibility issues are still present in the 2026 evidence set;
• MCPVerdict marks MCP 2026-07-28 compatibility as incomplete.

Filesystem MCP is the official reference Model Context Protocol server for letting an MCP-compatible AI client read, search, inspect, create, edit and move files inside explicitly allowed local directories.

The canonical package is @modelcontextprotocol/server-filesystem. It runs locally as a Node.js process over stdio, requires no API key or OAuth token, and inherits the operating-system permissions of the process that launches it.

The crucial distinction is that it is not intended to grant unrestricted machine access. The server combines the process's own OS permissions with an MCP-level allowed-directory list, so its effective authority is:

Operating-system process permissions ∩ Filesystem MCP allowed roots.

The current server documents 13 tools. Nine are read/inspection operations and four can mutate the filesystem. The capability set is intentionally narrow: it handles files and directories rather than shell execution, web browsing, Git hosting or databases.

Directories can be supplied when the server starts or, in clients that support it, supplied dynamically through MCP Roots. Filesystem operations are validated against the currently allowed roots.

Real-path and symlink containment

The current implementation does more than compare raw path strings. It resolves/canonicalizes targets and checks real paths against the allowed directories. Independent September 2026 testing of filesystem MCP implementations found the official reference server revalidating resolved entries during recursive traversal, which materially improves resistance to symlink escape.

Roots can change the active boundary

A subtle operational behavior matters here: when a connected client supplies MCP Roots, the current design can replace the CLI-provided allowed-directory set rather than merge with it. That often narrows access, but it can make scope less predictable—directories may disappear and the operator may believe one policy is active while another is actually in effect.

Use list_allowed_directories after setup changes or client switches. For a security-sensitive server, knowing the actual active boundary matters almost as much as choosing a narrow one.

Filesystem MCP has strong current directory-containment mechanics, but granting an AI filesystem access remains a high-authority action. The server can be configured safely; it cannot make a poor permission choice safe.

What the server protects well

• operations are constrained to allowed roots;
• current path validation uses canonical/real paths rather than trusting raw strings;
• modern recursive operations re-check entries against the allowlist;
• current tools advertise openWorldHint: false, reflecting local filesystem scope rather than open-network access;
• no API key, OAuth token or third-party MCP host is required.

What directory scoping does not solve

• hidden files inside the root remain accessible;
• an allowed project can still contain .env, .npmrc, credentials or private exports;
• write authority can modify valid files;
• malicious instructions inside local files can still become model input;
• a home-directory allowlist can expose far more data than the task requires while still staying inside the sandbox.

Historical symlink vulnerability

Older releases had a high-severity symlink/path-validation advisory. That history matters because the entire security claim depends on resolving something like /allowed/project/link → /outside/secret before approving access. Modern releases are not the same design as those vulnerable versions, and current independent testing is materially more positive.

../ is not proof of a current sandbox escape

Path schemas can accept strings containing traversal syntax, but schema permissiveness and runtime containment are different layers. The evidence set supports the more precise conclusion: schema-level defense could be stronger, while current real-path validation is considerably stronger than a raw ../ string check.

Filesystem MCP is not a read-only connector. Its value comes partly from modifying local work, which is also why it deserves stronger safeguards than a documentation-only MCP.

write_file

write_file creates a file or overwrites an existing file. The tool is correctly marked destructive-capable. Use it only where replacement is acceptable or version control/backups make recovery easy.

edit_file

edit_file is the strongest mutation design in the server because it supports dryRun: true and can return a diff before an edit is applied. The limitation is that dry-run is guidance rather than enforced policy—the default is not automatically safe-preview-first.

move_file

A reproduced August 2026 report against version 2026.7.10 found move_file silently overwriting an existing destination even though the documentation said it should fail. That is a real data-loss class behavior. Until the exact deployed release is verified against the fix, treat moves onto potentially occupied destinations as high risk.

The server's boundary is the allowed directory, not “the files the agent probably needs.” Dotfiles and dot-directories are not automatically excluded.

If an allowed project contains .git, .env, .terraform, .npmrc, generated artifacts or local credential/config files, those files can become part of the agent's searchable/readable space.

This affects both security and efficiency. Recursive search/tree calls can surface irrelevant metadata and secrets while also consuming large amounts of context. Use narrow roots and exclusion patterns rather than assuming hidden content is filtered for you.

Filesystem MCP has a relatively small fixed tool surface: 13 tools. MCPVerdict estimates the complete tool-schema footprint at roughly 3K–6K tokens per session, depending on the client, schema serialization and target tokenizer.

The bigger variable is usually the tool result, not the schema. A tiny metadata call is cheap. A recursive directory tree, multi-file read, large search result or media payload can dwarf the fixed 3K–6K definition cost.

Model-window sources checked Sep 27, 2026: OpenAI current model/API pages; Anthropic model and Bedrock context documentation; Google Gemini 3.8 Flash docs; xAI Grok 4.6 docs; Mistral model docs. Percentages are arithmetic reference shares, not tokenizer-specific measurements of the actual Filesystem MCP schema.

The practical rule

Do not optimize only for tool-definition count. A 6K fixed schema is modest on a 1M-token model, but one badly scoped directory_tree over node_modules, .git, build output and caches can cost more than the entire schema many times over.

The MCP server itself costs $0: there is no subscription and no third-party API requirement. Model usage is the variable cost.

A realistic evaluator run would test normal reads, outside-root refusal, traversal, symlink escape, recursive search, dry-run editing, actual edits, overwrites, move collisions and hidden-file exposure. The working budget used here is approximately 30K input + 8K output tokens.

Prices were checked against current vendor pages on Sep 27, 2026 where available. They are examples for the stated token budget, not a permanent price promise; caching, long-context tiers, regional processing and promotions can change the bill.

Wall-clock test budget

• install and configure: about 2–5 minutes;
• 12-task safety/function gauntlet: about 20–30 minutes;
• review: about 10 minutes;
• total: roughly 30–45 minutes.

The hidden costs matter more

• accidental file loss from write/move operations;
• secret exposure when broad roots include sensitive files;
• token explosion from recursive trees/searches;
• operator confusion when Roots change the active allowlist;
• duplicating native filesystem tools already provided by the AI client.

MCPVerdict currently marks compatibility as not yet complete. The repository's current source metadata still uses @modelcontextprotocol/sdk ^1.30.0, while the Filesystem README continues to recommend MCP Roots for dynamic directory control.

That combination is the basis for the compatibility score of 72: the server is broadly usable across stdio clients, but its lifecycle and Roots model still reflects the earlier protocol generation rather than a clean current-spec migration.

The canonical server is a local stdio MCP process, so any client that can launch a local stdio server can potentially use it. The important distinction is evidence strength: some clients document the local stdio path clearly, while others should be verified against their current MCP configuration before you rely on them.

The install is simple. The permission choice is not. Start with one disposable or version-controlled project directory; verify the active boundary; only then widen access if the workflow actually needs it.

NPX / standard stdio configuration

For JSON-based clients that use the common mcpServers shape, the canonical package can be launched with one or more allowed-directory arguments:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/absolute/path/to/project"
      ]
    }
  }
}

The final path is not decorative configuration—it is the security boundary. Prefer an absolute project path over a home directory.

Cursor project configuration

Cursor supports project-level .cursor/mcp.json. That is a strong match for Filesystem MCP because the configuration can live beside the project whose files you intend to expose.

Docker for stronger isolation

Docker can create a second independent boundary: the container can only see mounted paths, and Filesystem MCP then applies its own allowlist inside that view. For read-only evaluation, mount the project read-only first.

docker run -i --rm   -v /absolute/path/to/project:/workspace:ro   mcp/filesystem   /workspace

After confirming reads, use a separate disposable writable directory for edit/move tests rather than turning the whole project writable immediately.

The 2026 issue history shows that not every Filesystem MCP failure is user configuration. Start with the simplest boundary/runtime checks before blaming the client or server.

Restart and verify

Many local MCP clients load server definitions at startup or on explicit reload. After changing the config, restart/reload the MCP host and confirm both the tool list and list_allowed_directories rather than assuming the edited file was picked up.

Filesystem MCP is most useful when an agent needs repeatable directory access rather than a one-off file upload. The value comes from persistent, scoped access; the risk comes from the same persistence when the root is too broad.

Use it when it adds a controlled filesystem capability your client does not already provide, or when you need a standardized MCP interface to a directory outside the client's native workspace.

It can be redundant in coding agents that already have strong native read/search/patch/create tools scoped to the current project. In that case the adoption question is not “Can Filesystem MCP edit files?” but “Does it add useful scope or portability without duplicating tools, increasing context and creating another permission surface?”

Filesystem MCP is a simple server with an unusually important security boundary. Unlike cloud MCPs, it needs no token and does not send filesystem requests to a third-party MCP host. Modern releases also appear to handle real-path and symlink containment well, including recursive operations—the single most important technical requirement for an allowed-directory sandbox.

The danger is mostly configuration and mutation authority rather than product complexity. Once a directory is allowed, hidden files and sensitive project artifacts are generally fair game, while write/edit/move tools can change real local data. The safest default is one project directory, preferably container-mounted, read-only until write capability is actually needed.

Its remaining strategic weakness is protocol age: the current implementation still leans on the earlier Roots/SDK v1 model, and the 2026 evidence set contains enough client, path and destructive-write bugs to justify Moderate rather than High verdict confidence.

Recommended when the root is narrow. The same server becomes a bad default when the root is broad.

The verdict uses current package data, recent security research and issue evidence rather than treating the README as the complete truth. Positive findings and negative reports are separated so one bug does not erase the underlying architecture—and one good security audit does not erase real operational failures.

Evidence confidence: strong corpus; overall verdict confidence Moderate because the current 2026.8.31 package was not independently run through the full live gauntlet in this profile.

Primary/recent sources: canonical source · npm package · move overwrite issue · Roots replacement issue · historical advisory · Sep 2026 filesystem MCP security survey.