@neonlightdev/mcp-server-filesystem-ignore
MCP serverVerified · Rung 3Official Anthropic filesystem server fork with opt-in gitignore-style filtering for directory listing, traversal, and search. Adds --respect-gitignore and --ignore-file startup flags. Security model, tool contracts, and all 14 tools inherited unchanged from upstream. Maintains an explicit upstream sync baseline for future replay.
Score breakdown
Based on 1 evaluation. Confidence rises as more independent tests agree.
The verdict
A clean, single-purpose fork of the official Anthropic filesystem server. The only additions are --respect-gitignore and --ignore-file startup flags that filter listing, traversal, and search results. Every other behavior (tool contracts, security model, error messages, path handling) is inherited unchanged from upstream (documented as upstream v0.6.3, commit f4244583). All 14 tests pass. Path traversal is blocked, the allowlist is enforced, and security works identically to the reference implementation. The ignore filtering is scoped correctly: listing and search omit matched paths; read_file reads any allowed path regardless of ignore rules, which is the right behavior for a listing feature and not a security bypass. The package documents its upstream baseline and includes a replay-based sync workflow, which makes it easy to evaluate how current the fork is. This is what a fork should look like. Use it over the official package if your agent workspace has noisy directories (node_modules, .git, build artifacts) that you want excluded from listings without changing read access.
What this grade covers, and what it does not
This server was tested on Jun 7, 2026, 2 months ago, against the version pinned on this page. The battery covered direct reads and writes outside the workspace, dotdot traversal, and symlink-follow escapes. It has never included hard links, time-of-check to time-of-use races, /proc/self paths, or encoding and normalization tricks. Those vectors are specified and not yet run.
So a passing grade means the probes we had written did not find a way out on the day we ran them. It does not mean none exists. Three servers in this category held a passing grade until a symlink probe was written, and then all three returned /etc/passwd. Nothing about those servers changed; our coverage did. Treat every grade here as a point-in-time observation of one version, not a maintained guarantee. Nobody is re-running these on a schedule yet.
Deploying MCP servers and need more than a point-in-time read? We run private evaluations against your actual configuration. marcel@koca.co.
Security findings
Flags from our evaluations, ordered by severity.
- Info
IGNORE_IS_LISTING_ONLY
The gitignore filtering applies only to list_directory, list_directory_with_sizes, directory_tree, and search_files. read_file reads any path within allowed directories regardless of ignore rules. This is correct and documented behavior, but users who expect ignore rules to act as access control will be surprised.
Test history
1 runEvery evaluation behind the score. This is the receipt.
- PassmanualReliability
92/100
Latency1 ms
SetupEasy
Flags1
All 14 tools verified via sandbox (Node v22). Tools: read_file, read_text_file, read_media_file, read_multiple_files, write_file, edit_file, create_directory, list_directory, list_directory_with_sizes, directory_tree, move_file, search_files, get_file_info, list_allowed_directories. Without ignore flags: node_modules and .git both appear in listings (correct upstream behavior). With --respect-gitignore: node_modules and *.log hidden from list_directory and directory_tree, non-ignored files still shown, .gitignore processed correctly. With --ignore-file: custom ignore patterns applied. read_file reads gitignored files without error (correct: ignore is listing-only, not access control). 14/14 tests passed.
InfoIGNORE_IS_LISTING_ONLY