MCP server · Model Context Protocol (reference server)
Filesystem MCP Server
The reference MCP server for local file access: read, write, edit, move and search files inside directories you explicitly allow.
What it is, and what it costs you
The filesystem server is the canonical example of MCP's design and the clearest illustration of why the protocol needs governance. It grants an agent direct read and write access to the local disk, bounded by a list of allowed directories supplied at launch. That boundary is the entire security model, and it is configured in a text file that nobody reviews.
It is worth being precise about what the allowlist does and does not do. It constrains which paths the server will operate on — genuinely useful, and better than the alternative. It does not constrain what the agent does with the contents once read. A file read from an allowed directory is now in the context window, and from there it travels wherever that session's egress permits.
The common misconfiguration is scope creep by convenience. An engineer starts with one project directory, hits a case where the agent needs something from a sibling repository, and widens the allowlist to the home directory or the drive root. At that point the server can read SSH keys, cloud credential files, browser profiles, password manager exports, and every other repository on the machine — and the widened config persists long after the task that motivated it.
Write access deserves separate consideration from read access, because it is a different kind of incident. A misled agent with write access can modify a build script, a CI configuration, a git hook, or a dotfile — turning a one-time injection into persistent code execution that outlives the session.
Capability profile
What this server can reach, and why a security team cares. These are capabilities the server has by design — derived from the publisher's documentation, not from a scan.
- filesystem read
Anything inside an allowed directory is readable, including secrets and credentials that happen to live there. Scope is the only control.
- filesystem write
Modifying build scripts, git hooks, CI config, or shell profiles converts a transient injection into persistent execution on the machine.
- directory enumeration
Listing and searching reveals project structure, internal naming, and the location of credential files even where contents are not read.
Restrict this before you roll it out
- Allowlist the narrowest workable directory
One project directory, never the home directory or a drive root. Widening it 'temporarily' is how most over-permissioned configurations happen.
- Keep credentials outside allowed paths
Verify that no allowed directory transitively contains .env files, SSH keys, cloud credential directories, or password exports.
- Prefer read-only where the task allows
Analysis, review and explanation workflows need no write access, and removing it eliminates the persistence risk entirely.
- Pair with egress restriction
Read access is only an exfiltration risk if the session can reach the network. An egress allowlist is the cheaper half of this control.
Vincosha Assay assessment
not yet assessedWe have not published a scan verdict for Filesystem MCP Server.
Everything above is a capability profile compiled by hand from the publisher's own public documentation on 2026-07-25. It describes what this artifact can reach and what to restrict before rolling it out. It is not a security verdict, and it should not be read as one.
When Vincosha Assaypublishes an assessment for this artifact it will appear here with a verdict, the findings behind it, and the date it ran. We would rather leave this space empty than fill it with a guess — inventing a security verdict about somebody else's software would be both wrong and dangerous.
What an assessment covers
- prompt-injection patterns in descriptions and instructions
- credential reads and outbound egress in bundled code
- over-scoped permissions and manifest claims
- typosquatted and impersonating names
- tool-manifest drift since the last approval
- content hash against the version you approved
Sources
This profile was compiled from the publisher's own documentation. Products change — verify against the source before making a decision that depends on a specific detail.